Problems while transferring big files

[Matt McCutchen]

On Mon, 2009-03-09 at 10:34 +0100, Boniforti Flavio wrote:
> > That is just the error code and its interpretation.  What 
> > error message comes prior to that?
> 
> This is the whole log:
> 
> /usr/bin/rsync -rtzv --port=8873 --delete --ignore-errors --numeric-ids
> \
>     --delete-excluded --stats --progress localhost::Carlo/ \
>     /mnt/remote/Customer/daily.0/Carlo/
> receiving incremental file list
> Architettura/
> Architettura/Shot.avi
>    236093440  32%   25.73kB/s    5:20:01  /usr/bin/logger -i -p user.err
> -t rsnapshot /usr/bin/rsnapshot -c \
>     /root/Customer.conf daily: ERROR: /usr/bin/rsync returned 12 while \
>     processing localhost::Carlo/

You are missing rsync's output to stderr.  There should be at a minimum
"rsync error: error in rsync protocol data stream (code 12)", and
probably a preceding error message that would give us an idea of what
the problem is.  Adjust your setup so you can capture the stderr, or if
all else fails, run the rsync manually.

> > We hypothesize that there can be an accidental match in the 
> > checksum data, which would cause the two sides to put 
> > different streams of data into their gzip compression 
> > algorithm, and eventually get out of sync and blow up.  If 
> 
> Don't understand what you mean, could you please explain?
> 
> > you have a repeatable case of a new file overwriting an 
> > existing file that always fails, and if you can share the 
> > files, make them available somehow (e.g. put them on a web 
> > server) and send the list (or me) an email on how to grab 
> > them, and we can run some tests.
> 
> Well, in *this* specific case the file I was syncing was totally new, it
> therefore didn't already exist on the receivers' side...

OK, then your problem is something other than the compression
false-match issue we were discussing.

-- 
Matt