On Wed, 2009-05-20 at 09:35 +0530, Jignesh Shah wrote: > Thanks Matt but I think that should not be a correct behavior. The > rsync > should retry the ESTALE files rather than giving errors immediately > and > deleting the files untimely.
ESTALE means the source file was deleted while rsync was reading it. (That's what I meant by untimely; rsync itself isn't deleting anything.) There's no point in retrying a deleted source file. I suppose rsync could treat the file as vanished, but that would require a protocol change to inhibit the receiver from applying the update without causing the redo or (if already redoing) exit code 23 that sending a bad checksum normally would. -- Matt On Wed, May 20, 2009 at 8:32 AM, Matt McCutchen <m...@mattmccutchen.net>wrote: > > > On Tue, 2009-05-19 at 15:49 +0530, Jignesh Shah wrote: > > > Hi, I am wondering how rsync-3.0.6 react if it encounters ESTALE > error > > > while synching? If I remember correctly then the rsync-2.6.0 > skipping > > > that file/dir in case of ESTALE error. > > > > If rsync encounters any kind of error reading a source file, it will > > report the error (causing an eventual exit code of 23) and skip the > > actual update to the destination file, unless --inplace was > specified, > > in which case the update has already been done. A second rsync run > will > > clean up any mess resulting from untimely deletion of source files. > > > > -- > > Matt -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
