rsync - Aug 2003 - [patch] New RC to differentiate partial xfers from files that get deleted before they're xfered

All,

During development of a backup solution with rsync I experienced some
failed backups because of RC 23, partial transfer. These were because the
application using the data I was backing up, was still active, and had
deleted a file inbetween rsync compiling the file list and then transfering
the file.

After some feedback from Wayne Davidson and JW Schultz suggesting the
solution to this, I've patched the rsync-2.5.6 code to acheive this
diferentiation with a new RC. If the only errors that occured during an
rsync session are 'file not found' when send_files attempts to send the
file, then we get RC 24, RERR_VANISHED, and some text to the same effect.
I've changed log.c to start the error messsage with "rsync
warning" instead
of "rsync error" to make it obvious this is not a failure condition.

I made these changes on the rsync-2.5.6 code instead of the HEAD stuff in
cvs, so I've included a diff -u against both the rsync-2.5.6 source and the
latest HEAD source.

Please let me know what you think.

Ev.

PS: I'm using lotus notes as my mailer so I hope it doesn't screw up the
attachments.

(See attached file: diff.rsync-2.5.6)(See attached file: diff.HEAD)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: diff.rsync-2.5.6
Type: application/octet-stream
Size: 3345 bytes
Desc: not available
Url :
http://lists.samba.org/archive/rsync/attachments/20030807/f6139e28/diff.rsync-2.5.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: diff.HEAD
Type: application/octet-stream
Size: 41423 bytes
Desc: not available
Url :
http://lists.samba.org/archive/rsync/attachments/20030807/f6139e28/diff.obj

On Thu, Aug 07, 2003 at 02:55:40PM +0100, Evan Skinner1
wrote:
> All,
> 
> During development of a backup solution with rsync I experienced some
> failed backups because of RC 23, partial transfer. These were because the
> application using the data I was backing up, was still active, and had
> deleted a file inbetween rsync compiling the file list and then transfering
> the file.
> 
> After some feedback from Wayne Davidson and JW Schultz suggesting the
> solution to this, I've patched the rsync-2.5.6 code to acheive this
> diferentiation with a new RC. If the only errors that occured during an
> rsync session are 'file not found' when send_files attempts to send
the
> file, then we get RC 24, RERR_VANISHED, and some text to the same effect.
> I've changed log.c to start the error messsage with "rsync
warning" instead
> of "rsync error" to make it obvious this is not a failure
condition.
> 
> I made these changes on the rsync-2.5.6 code instead of the HEAD stuff in
> cvs, so I've included a diff -u against both the rsync-2.5.6 source and
the
> latest HEAD source.
> 
> Please let me know what you think.
> 
> Ev.
> 
> PS: I'm using lotus notes as my mailer so I hope it doesn't screw
up the
> attachments.
It did but not so badly i couldn't look at them with extra
effort.  They should be text/plain no encoding.

The HEAD diff is too big to be just your changes.  Please
get HEAD and apply the changes to that for patches.  Also
your patch was reversed.  It should be diff -u base new.
Once you get CVS running you can simply use cvs diff -u to
get a diff against the HEAD and cvs update can keep you
current by automatically merging as long as there isn't too
much overlap.

Now for my comments.

Right idea.  However, i'd rather not create the new global
variable io_vanished.  Instead let's turn io_error into a
bitmask.  Currently the only values it uses are 0 and 1.
If you produce a patch that just makes the change to a
bitmask and uses a

	#define IOERR_GENERAL 1

I'll be glad to commit it quickly.  That will generalise
io_error handling so we can grow with it.  I may be able to
build on that for the read error in file_map.

-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw@pegasys.ws

		Remember Cernan and Schmitt