rsync does hours of "fake-work" after failure

Ben RUBSON ben.rubson at
Fri Oct 6 10:53:10 UTC 2017

> On 06 Oct 2017, at 12:24, Frank Steiner via rsync <rsync at> wrote:
> Hi,
> I just stepped on a strange and very annoying bug in rsync-3.1.0 as
> shipped with SuSE Linux Enterprise 12, but verified the bug also
> with rsync-HEAD-20170123.
> I tried to copy some of my movie collection to a usb disk that our
> TV could read, so it was formatted with vfat. I forgot that vfat can't
> handle files > 4 GB, and some of the movies were larger.
> rsync worked for 3 hours copying hundreds of GB, but after it had
> finished the last file it complained
> rsync: write failed on "/media/disk/some_movie.mpg": File too large (27)
> rsync error: error in file IO (code 11) at receiver.c(389) [receiver=3.1.0]
> This file had been the third in the list of files to copy, and when
> I looked at the usb disk I saw that the two files before and 4 GB of
> some_movie.mpg had been copied. But the 400 GB of the remaining files
> had not! rsync had claimed to copy each of it, and as I use "-avP" 
> I had indeed been watching the progress. The speed and the MB/s
> were the usual values for copying to the USB disk.
> So rsync doesn't stop and fail at the point it sees the first file
> too large for vfat, it just goes on and "fakes" the rest of the
> process :-) And because it took some hours, this was a real bad
> surprise at the end. 
> Below is the output of a little test that can easily be reprocuded.
> Is this a known bug? I couldn't find something similar in bugzilla 
> or the mailinglist archives.


I encountered same issue and proposed the following patch :

Perhaps you should give it a try ?


More information about the rsync mailing list