FS#6648 - Creating two files with similar names corrupts FAT directory

Attached to Project: Rockbox
Opened by Dave Chapman (linuxstb) - Monday, 12 February 2007, 01:20 GMT
Task Type Bugs
Category Operating System/Drivers
Status Closed
Assigned To No-one
Operating System All players
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


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.
This task depends upon

Closed by  Peter D'Hoye (petur)
Saturday, 24 February 2007, 21:23 GMT
Reason for closing:  Fixed
Comment by Peter D'Hoye (petur) - Sunday, 18 February 2007, 00:58 GMT
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.

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)
Comment by Jonas Häggqvist (rasher) - Sunday, 18 February 2007, 22:05 GMT
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?
Comment by Peter D'Hoye (petur) - Sunday, 18 February 2007, 22:15 GMT
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
Comment by Jonas Häggqvist (rasher) - Sunday, 18 February 2007, 22:22 GMT
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.
Comment by Peter D'Hoye (petur) - Sunday, 18 February 2007, 22:34 GMT
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....
Comment by Peter D'Hoye (petur) - Sunday, 18 February 2007, 23:03 GMT
Just found out that rockbox _always_ creates a longname, which isn't quite the way to do it...

note to self: page 30+ illustrates how we really should be creating shortnames.
Comment by Peter D'Hoye (petur) - Wednesday, 21 February 2007, 23:58 GMT
This patch implements shortfilename creation close to above spec.
As a bug in it can be nasty (filesystem), please review...
Comment by Peter D'Hoye (petur) - Friday, 23 February 2007, 20:27 GMT
final draft