rsync returns 23 (RERR_PARTIAL) when a file has been deleted after the list has been created.

jw schultz jw at
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.)
> Thoughts?

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

		Remember Cernan and Schmitt

More information about the rsync mailing list