• 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
Attached to Project: Rockbox
Opened by linuxstb - 2007-02-12

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.

Closed by  petur
2007-02-24 21:23
Reason for closing:  Fixed
petur commented on 2007-02-18 00:58

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)

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?

petur commented on 2007-02-18 22:15

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.

petur commented on 2007-02-18 22:34

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….

petur commented on 2007-02-18 23:03

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.

petur commented on 2007-02-21 23:58

This patch implements shortfilename creation close to above spec.
As a bug in it can be nasty (filesystem), please review…

petur commented on 2007-02-23 20:27

final draft


Available keyboard shortcuts


Task Details

Task Editing