Public bug reported: 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://forum.snapcraft.io/t/snapd-causes-corruption-on-upgrade/5253for all the details. 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://github.com/dosfstools/dosfstools/commit/4f953bb5d74e0eeda6cbee1e4871513edc7b912b ** Affects: dosfstools (Ubuntu) Importance: Undecided Status: New ** Description changed: + 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://forum.snapcraft.io/t/snapd-causes-corruption-on-upgrade/5253for all the details. 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://github.com/dosfstools/dosfstools/commit/4f953bb5d74e0eeda6cbee1e4871513edc7b912b -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1776523 Title: When repairing files with long filenames can create duplicates To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dosfstools/+bug/1776523/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
