When repairing files with long filenames can create duplicates
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| dosfstools (Ubuntu) |
New
|
Undecided
|
Unassigned | ||
Bug Description
Bugreport here so that we can SRU dosfstools with the fix:
On Ubuntu Core system we found a bug with fsck.vfat. When it repairs a file that has a long filename it may rename it to FSCK0000.000 - however it does not rename/replace the long-filename. Which means that the vfat driver in the kernel may report the same name for two files. See https:/
The original upstream report is:
"""
I ran into the issues that I had a filesystem with two "uboot.env" files.
On closer inspection it become clear that the image contained a file called "FSCK0000.000" with the lfn (long-file-name) "uboot.env". The image also contains a "UBOOT.ENV" (as a regular FAT16 name). When this is mounted via the vfat kernel driver two "uboot.env" files appear. Which is confusing :) Mounting it as "msdos" helpered to solve the mystery.
After looking at fsck.vfat I suspect that what happens is there was a corrupted entry for the uboot.env file which fsck.vfat corrected via auto_rename() in check.c. However this auto_rename() seems to only set the short filename. Any lfn-names remain untouched AFAICT. Which I suspect leads to the confusing result above.
"""
The upstream fix is in https:/
