rsync returns 23 (RERR_PARTIAL) when a file has been
deleted after the list has been created.
jw at pegasys.ws
Thu Aug 7 22:46:30 EST 2003
On Thu, Aug 07, 2003 at 12:49:49PM +0100, Evan Skinner1 wrote:
[and oddly reordered to be back-assword and attribution missing]
> > 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.
> A new error code for only ENOENT errors sounds great - whilst
> keeping the old 23 code for all other partial transfers.
> > 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.
> I've made changes to the code to this effect and tested that
> it gives the desired results. The RERR_VANISHED RC is only
> returned if the only errors that occured are ENOENT during
> send_files. I'm going to use this modified rsync for my project.
> Is there a place to submit these code changes or should I leave
> you guys to make the change in due course?
Send a diff -u to the mailing list. Preferably against
current CVS. Do it either inline (no line wrapping or
whitespace conversions) or as a text/plain attachment.
If, like this message, it isn't part of a thread include an
executive summary and put [patch] on the front of the
descriptive subject line.
That way anyone can see it, comment, or try it.
> 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?
J.W. Schultz Pegasystems Technologies
email address: jw at pegasys.ws
Remember Cernan and Schmitt
More information about the rsync