High,
I am experiencing a problem with rsync. The symptom is that rsync does
not seem to notice that the file at the target side is shorter then the
source one and then does not update the file. This leaves me with
corrupted files at the target side. Now, this does not happen all the
time but only for few files. My environment:
- rsync 2.6.2 on Tru64 unix 5.1
- I am copying from a local file system to an AFS file system.
- My command line: rsync -ruzv /home/TRICS/data/2004/ \
/afs/psi.ch/project/sinqdata/2004/trics/
- The file size is several MB. The files are frequently appended to
by our instrument control software. There may be a reading/writing
synchronisation problem.
- If I delete the file at the target end, a rerun of rsync copies it
nicely.
As this does not happen very often this must be quite difficult to track
down. Any ideas how to get this sorted? I think rsync should notice that
files are of different size and copy them then.
Best Regards,
Mark Koennecke
On Thu, Jul 22, 2004 at 04:03:26PM +0200, Mark Koennecke wrote:> - My command line: rsync -ruzv /home/TRICS/data/2004/ \ > /afs/psi.ch/project/sinqdata/2004/trics/The -u option tells rsync to ONLY update the file if the timestamp is earlier than the timestamp of the sending file. This will override the normal size/date check, which is why rsync isn't updating the file. How it got corrupted (most likely) is that the file changed during the transfer and rsync put the result of the transfer into place on the destination pending a resend. (This broken behavior was fixed in the CVS version a while back so that (a) we discard a file that failed to verify unless --partial was specified, and (b) we don't set the timestamp on a file that failed to verify when we do keep it.) Are you using the -u option for some other reason? If not, I'd suggest dropping it. ..wayne..