fsck.vfat truncates files of 4294967295 bytes length to 0 bytes at boot-time

[Stefan Güls]

Binary package hint: dosfstools

After a fresh dapper(server) install, the running dosfstools-filesystemcheck chose to truncate all the files of my backup images (living on a fat32 fs and having 4294967295 bytes length, because thats the maximum on fat 32) to zero bytes length.... :-(

a chkdsk from Windows was able to restore the files to their original length.

Steps to reproduce: Install dapper with default options and boot it, with a vfat partition partition present and files with the above mentioned file lenght on them.

[StefanPotyra (sistpoty)]

Hi,

I've just been trying to reproduce this bug, but I couldn't. Is there anything special apart from the file length (my test file has identical length) that might give a hint where to dig?

Thanks,
     Stefan.

[StefanPotyra (sistpoty)]

confirming this (retried with i386, and could reproduce it) and assigning to me.

[dave hartley (jupiter-booth9)]

I just had an almost identical experience with a fresh xubuntu install on a dual boot set up with win98.

I had edited /etc/fstab to create a mount to a shared vfat partition which among other things contained my Acronis True Image disc image files in .tib format. True Image splits the image into a set of linked files each being the maximum size for a fat32 partition. (I did wonder whether the problem related to the way True Image creates this linked set rather than the file size).

The fstab line I added was :

/dev/hda5 /media/hda5 vfat defaults,umask=000 0 2

thus setting the fsck option to check this vfat partition.

On re-booting when it got to the file system checking part of the boot-up sequence a mismatch between the nominal size of the first .tib file in the set and its actual size on the disc caused it to truncate the file to 0 bytes. The boot-up sequence then hung before it could start on anything else and I killed it.

I edited the fsck option to 0, recreated my image files and tried booting up xubuntu. So far it hasn't eaten my .tib files again :)

[Stefan Güls (sguels)]

> which among other things contained my Acronis True Image disc image files in .tib format

hey, that's /exactly/ the type of files dosfsck was eating in my case, too...

After a conversation with StefanPotyra on IRC he could reproduce this, a fix should be on the way...

[Daniel T Chen (crimsun)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Tue, 19 Dec 2006 02:21:45 +0100
Source: dosfstools
Binary: dosfstools
Architecture: source
Version: 2.11-2.1ubuntu2
Distribution: feisty
Urgency: low
Maintainer: Roman Hodek <email address hidden>
Changed-By: Stefan Potyra <email address hidden>
Description:
 dosfstools - Utilities to create and check MS-DOS FAT filesystems
Changes:
 dosfstools (2.11-2.1ubuntu2) feisty; urgency=low
 .
   * Fix some integer overflows in check.c and fat.c which resulted in
     large files (close to 32-bit limit) being errorenously truncated
     to 0 bytes. Closes LP#62831.
Files:
 e62c97fb3c6f2010ac79f55f7ec83ee0 573 otherosfs optional dosfstools_2.11-2.1ubuntu2.dsc
 05e3eeb403a651f0ff51a04f9e1103b0 10133 otherosfs optional dosfstools_2.11-2.1ubuntu2.diff.gz

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFFh0WEe9GwFciKvaMRAmXhAJ0U0S/AlrMLiAz7vPLkzBAG/w54qQCgwI4p
SCAhY5HyXQCyR6C8HqovFBQ=
=hJLg
-----END PGP SIGNATURE-----

Uploading to ubuntu (via ftp to upload.ubuntu.com):
  dosfstools_2.11-2.1ubuntu2.dsc: done.
  dosfstools_2.11-2.1ubuntu2.diff.gz: done.
  dosfstools_2.11-2.1ubuntu2_source.changes: done.
Successfully uploaded packages.

[Wenzhuo Zhang (wenzhuo)]

Dapper, with latest updates, still hangs when dosfsck'ing a FAT32 partition with such a big file in it. Please backport the bug fix to dapper. Thanks

[Onno Benschop (onno-itmaze)]

Wenzhuo Zhang, I have now nominated this fix for a release in Dapper.

[Onno Benschop (onno-itmaze)]

Bug #62831 bug describes a situation where data is truncated if it is of a specific length, namely 4Gb -1 byte. dosfschk incorrectly truncates the file causing data loss on a FAT partition.

The fix for the bug is applied to the same source version as is released under edgy and is also the same as is released under feisty.

I suspect that this should also be released to edgy, thus making this an update for both dapper and edgy users. Dapper being the more important as an LTS release IMHO.

[Onno Benschop (onno-itmaze)]

The patch for this was not released with this bug, it was release with Bug #68153. The patch is here:

https://bugs.launchpad.net/ubuntu/+source/dosfstools/+bug/68153/comments/5
http://librarian.launchpad.net/5450768/dosfstools_2.11-2.1ubuntu2_to_3.debdiff

(FYI, patch ubuntu2 was a bad patch and should be ignored.)

[Onno Benschop (onno-itmaze)]

I will be off-line until the 2nd of June starting from tomorrow. I will be getting back to this when I return, and would welcome anyone else helping with the process while I am away.