Bug 147541 - rsync creating truncated files on fat32 filesystem
rsync creating truncated files on fat32 filesystem
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Alexander Viro
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2005-02-08 18:13 EST by Karen Bruner
Modified: 2007-11-30 17:07 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-05-18 09:29:16 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Karen Bruner 2005-02-08 18:13:13 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5)
Gecko/20041107 Firefox/1.0

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

How reproducible:

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.

Additional info:

We are using kernel-smp-2.4.21-27.0.2.EL
Comment 1 Karen Bruner 2005-02-10 14:44:33 EST
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
the filesystem.
Comment 2 Jay Fenlason 2005-02-10 14:55:06 EST
I'm reassigning to the kernel maintainers. 
Comment 3 giulioo 2005-02-11 08:49:15 EST
"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
to 4GB).

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.
Comment 4 Ernie Petrides 2005-02-25 19:27:35 EST
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.
Comment 5 Tim Powers 2005-05-18 09:29:16 EDT
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.


Note You need to log in before you can comment on or make changes to this bug.