- Status Closed
- Percent Complete
- Task Type Bugs
- Category Operating System/Drivers
- Assigned To No-one
- Operating System All players
- Severity Low
- Priority Very Low
- Reported Version
- Due in Version Undecided
-
Due Date
Undecided
- Votes
- Private
FS#6648 - Creating two files with similar names corrupts FAT directory
Steps to reproduce:
1) Write a .cfg file called “config01.cfgA” 2) Write a second .cfg file called “config01.cfg” (this should have different content to the first - change at least one setting, or just export a theme .cfg)
Accessing the device (I’ve tested with both an ipod 5g and h140) from Linux and Mac OS X will show two entries with identical filesizes and timestamps. A diff between the two files will show no differences.
Mounting the device in Linux with “-t msdos” doesn’t show the same problem - the two files have different shortnames, and the filesizes and timestamps are different, and a diff will show differences.
In WinXP, the files show different sizes and dates, but when displaying them (I used “type config.cfg” in a cmd prompt), they are both showing the content of the first file written.
Loading...
Available keyboard shortcuts
- Alt + ⇧ Shift + l Login Dialog / Logout
- Alt + ⇧ Shift + a Add new task
- Alt + ⇧ Shift + m My searches
- Alt + ⇧ Shift + t focus taskid search
Tasklist
- o open selected task
- j move cursor down
- k move cursor up
Task Details
- n Next task
- p Previous task
- Alt + ⇧ Shift + e ↵ Enter Edit this task
- Alt + ⇧ Shift + w watch task
- Alt + ⇧ Shift + y Close Task
Task Editing
- Alt + ⇧ Shift + s save task
Writing “config01.cfgA” creates a shortname called “config01.cfg” along with the longname.
Writing “config01.cfg” afterwards is problematic because “config01.cfg” is a valid 8.3 name using 1 entry, so no longname. The shortname can’t be randomized because it’s our real filename.
Solution:
1) always randomize shortname if it differs from longname
2) also scan the (invisible) shortnames when trying to create a new file
(work in progress)
Randomizing the shortname doesn’t really solve the problem where you create a file with a 8.3 name, where another file has this as shortname (it does make it less likely to happen, but the problem’s still there). A solution could be to scan for shortnames that match the new (8.3) filename, and change it if a file matches.
Would there be any problem with changing the shortname of an existing file?
Windows does as mentioned above and will complain if the shortname already exists.
Randomizing lowers the chance enough.
Scanning on shortnames is needed to avoid directory corruption
I tested it just now, after making that comment, and Windows (XP) did not complain, but silently changed the shortname of the existing file.
I did this:
create testdokument.txt, this gets the shortname testdo~1.txt
create testdo~1.txt, the shortname of testdokument.txt is changed to testdo~2.txt, and testdo~1.txt is created as requested.
This seems like the right thing to do to me.
Heh, indeed it does in GUI, it didn’t on the commandline… talk about consistency within the OS ;)
I did get a hint of what happened because I used config01.cfgA and config01.cfg and when I wanted to make config~1.cfg I got a msgbox telling me that changing the extension could make the file unusable. This was generated by the routine that changed the config01.cfgA shortname….
Just found out that rockbox _always_ creates a longname, which isn’t quite the way to do it…
note to self:
http://www.rockbox.org/twiki/pub/Main/DataSheets/FAT32Spec103.pdf page 30+ illustrates how we really should be creating shortnames.
This patch implements shortfilename creation close to above spec.
As a bug in it can be nasty (filesystem), please review…
final draft