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): rsync-2.5.7-5.3E How reproducible: Sometimes 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
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.
I'm reassigning to the kernel maintainers.
"The vfat file system and Linux" http://www.osnews.com/story.php?news_id=9681 ".. 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. .."
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. http://rhn.redhat.com/errata/RHSA-2005-294.html