[Bug 1776523] [NEW] When repairing files with long filenames can create duplicates

[Michael Vogt]

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
Foundations Bugs, which is subscribed to dosfstools in Ubuntu.
https://bugs.launchpad.net/bugs/1776523

Title:
  When repairing files with long filenames can create duplicates

Status in dosfstools package in Ubuntu:
  New

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://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

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dosfstools/+bug/1776523/+subscriptions