The Samba-Bugzilla – Bug 12153
Possible malfunctions of rsync when destination is on fat32 filesystem
Last modified: 2016-08-15 15:07:53 UTC
I use rsync to transfer a large number of files locally from one disk to another.
rsync -avv --progress /media/source/ /media/destination/
source is on an ext4 filesystem
destination is on a fat32 filesystem
The destination disk was checked and found to be OK by the badblocks-command
The destination filesystem was freshly created by mkdosfs.
There are chinese characters in the filenames. Filename encoding is utf-8 on both source (defined by locales) and destination (reported by mount command).
Rsync ends up with an error message saying that a file from source is bigger than 4gb. So far, this is expected behaviour because of the file size limitation on a FAT32 filesystem.
Possible malfunction 1: Some other files smaller than 4gb are missing in the destination as well.
Possible malfunction 2: When repeating the rsync command (to resume the transfer), files are transferred that do already exist in the dest directory. The files match in creation time and in comparison by diff command. fsck does not report any errors. But nevertheless, some files are transferred again. I can see big files being transferred again using the --progress option.
Possible malfunction 2 might be somehow related to case sensitivity in filenames.
Possible malfunction 2: Files are missing in destination. These files have been shown to be transferred with the --progress option at a speed that exceeds the maximum write speed of the disk on which the destination filesystem lays on.
Have been picking on the problem.
I think that the problem with files which already exist in destination but are transferred again is not caused by rsync but by a time comparison mismatch which can occur when timestamp accuracy differs between source and destination filesystem.
It would be nice to add something to the manpage, section "--modify-window", that this option makes sense when timestamp accuracy of source and destination filesystem differs.
The reported problem remains that files are missing in the destination (and reported to have been transfered at a speed greater than possible)
This report might be a duplicate of 10675