• 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 Dave Chapman - 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  Peter D'Hoye
2007-02-24 21:23
Reason for closing:  Fixed
Peter D'Hoye 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)

Jonas Häggqvist commented on 2007-02-18 22:05

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?

Peter D'Hoye 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

Jonas Häggqvist commented on 2007-02-18 22:22

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.

Peter D'Hoye 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….

Peter D'Hoye 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.

Peter D'Hoye 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…

Peter D'Hoye commented on 2007-02-23 20:27

final draft


Available keyboard shortcuts


Task Details

Task Editing