Red Hat Bugzilla – Bug 147541
rsync creating truncated files on fat32 filesystem
Last modified: 2007-11-30 17:07:06 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5)
Description of problem:
Using rsync to copy a local directory tree to a mounted fat32
filesystem on a USB hard drive creates a large number of files at zero
bytes instead of the original full size. The files that are truncated
seem random, and running the same rsync command will often (but not
always) re-copy the file successfully. The original files vary in
size from a couple of kb to a couple of Mb. They are all readable by
the user running the rsync (generally root). The 0-byte files are
randomly distributed throughout the rsync run.
Since we are seeing other issues with the USB fat32 filesystems, I
originally thought it was related to fat32, but after I wrote a
replacement script in perl that relies on the File::Copy module, the
problem hasn't reappeared.
The filesystem is most definitely not full; rsync bails when the
filesystem fills up (I've seen this happen). It logs no errors when
it copies the file as 0 bytes, even if I give multiple -v flags.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Attach, partition USB drive
2. mkfs -t vfat <device>
3. mount -t vfat -o rw <device> <mountpoint>
4. rsync -avL <localdir> <mountpoint>
5. find <mountpoint> -type f -size 0
Actual Results: The find returned a large number of 0-byte files,
even though the originals were not 0 bytes.
Expected Results: The find should return no filenames if there were
no 0-byte files in the original directory tree.
We are using kernel-smp-2.4.21-27.0.2.EL
Well, this no longer seems to be a problem with rsync, but with the
fat32 filesystem getting somehow corrupted. Files my perl script
writes have now started appearing as 0 bytes, although the perl script
itself checks the size before it says they're ok and moves on, so I
guess the files are actually getting truncated sometime after writing.
The problem seems to grow exponentially as more files are placed on
I'm reassigning to the kernel maintainers.
"The vfat file system and Linux"
3.1. Lost Clusters
Under Linux Kernel 2.4.x., a limit of the cluster data type results in
data loss, as soon as the vfat file system holds around 130GB. In
Kernel 2.6.x., this problem was - rather accidently - solved, when
many variables were consequently provided with a new type. A detailed
description of this bug, including a testsuite and a patch (by Erik
Andersen) can be found here. (The patch also allows for file sizes up
If you, however, work with a 2.4.x. Kernel and have a "full" vfat
partition, be prepared to lose data: any written file in a new folder
will be lost after unmounting the file system. When you mount the file
system again, these files have a size of 0 and the clusters are in
limbo. You can delete the unassigned clusters via dosfsck.
Karen, I believe that the fixes committed to the RHEL3 U5 patch pool
on 5-Jan-2005 (in kernel version 2.4.21-27.6.EL) for bug 141388 will
also fix this problem. The U5 beta period will begin in a couple of
weeks. Please verify that this problem is resolved in U5 then, and
if not, please switch the status of this BZ back to ASSIGNED. Thanks.
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.