| 2018-06-12 16:44:49 |
Michael Vogt |
description |
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 |
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 |
|
