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

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.

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

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

> 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...

-----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.

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

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

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.

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.)

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.