rsync returns 23 (RERR_PARTIAL) when a file has been deleted
after the list has been created.
jw at pegasys.ws
Thu Aug 7 06:38:48 EST 2003
On Wed, Aug 06, 2003 at 09:54:47AM -0700, Wayne Davison wrote:
> On Wed, Aug 06, 2003 at 01:48:06PM +0100, Evan Skinner1 wrote:
> > I believe this is happening because between the time rsync compiles
> > the file list and the time rsync attempts to transfer the file the
> > application has deleted it.
> Yes, that can cause this error code to be returned.
> > I think that this particular transfer failure should not be flagged as
> > RC 23, as other RC 23 conditions are actual failures as opposed to the
> > file list becoming outdated during the copy process.
> Yeah, it's something that seems desirable to me (to differentiate this
> specific partial-transfer condition).
> One potential solution would be to not return an error code if the open
> failures were all ENOENT errors on the sending side.
> Another solution is to create a new file-vanished-during-transfer error
> (for when the open errors consisted only of ENOENT errors), but we'd
> give it error code 23 (for backward-compatibility reasons). All other
> partial-transfer errors would get a new error code with the same error
> text as before. (I wouldn't want to see a new option added to make this
> new separation selectable, though.)
I like the idea of splitting file vanished during transfer
(VANISHED) a lot.
I'd rather 23 stay partial transfer and file vanished be a
new error (24 or 40). When pulling you depend on the remote
end to set this error making this protocol dependent.
Your wrapper won't know it is running down-graded.
I'd rather have a VANISHED (warning) mistagged as a possibly
more serious PARTIAL (error) than have a more serious
PARTIAL tagged as a VANISHED. After all, PARTIAL usually
means you want to re-run but VANISHED can be ignored.
J.W. Schultz Pegasystems Technologies
email address: jw at pegasys.ws
Remember Cernan and Schmitt
More information about the rsync