File Corruption

Kevin Stussman kevins at
Mon Sep 12 15:36:27 GMT 2005

Thanks for the explanation.

Since I have no way to know if Oracle has completed the file, I solved
the problem by making the transfer process smarter and only deleting the
file once it has been successfully loaded into the secondary. This way
if the file was corrupted (i.e. sent before completed) then the next
round of rsync transfers will update the corrupted file with a 
completed version (just try try again :-)

I do have one other question...if rsync does do a checksum after
the file has been transferred, but the original file has been changed
during transfer, wouldn't the final checksum then fail? Or does it only
"snapshot" the original state of the file then compare with the checkum
the transfer. It would be good if rsync was smart enough to warn/retry
if the source has changed in transit.



On Fri, 2005-09-09 at 18:00 -0700, Wayne Davison wrote:
> On Fri, Sep 09, 2005 at 12:06:50PM -0600, Kevin Stussman wrote:
> > -  Is there way to ensure that rsync checks the integrity of the
> > transferred file when it is complete?
> Rsync validates that all the data it writes out matches the checksum of
> the data on the sending side.  The only known way to create a corrupted
> destination file is to specify --inplace and --sparse together (because
> it can make rsync think that it wrote some zeros when it didn't really).
> Since that doesn't seem to be your problem, the most likely cause is
> that the source file was in a corrupted state when it was copied (i.e.
> the data was currently being written on the sending side, and the update
> was not complete).
> ..wayne..

More information about the rsync mailing list