PATCH: better handling for write failures (disk full)

[John R. LoVerso]

> What are they against?

Sorry I forgot to mention this: 2.5.6.

> We have enough problems with needing to pour over the
> transfer report to find the cause of the "some files could
> not be transferred" error message.  I don't know that we
> want to add to it.

Part of the problem now is that if the receiver fails a write,
rsync aborts with a meaningless error because the receiver has
aborted with exit_cleanup().  People have asked about this before:

	http://lists.samba.org/pipermail/rsync/2003-March/010027.html

My first patch fixes that but at least allowing the reciever to properly
detect the error and sanely deal with the interrupted transfer.
Perhaps you could add a switch that said "continue on errors".

> Perhaps even more important, if one file fails due to a full
> filesystem it is likely others will.

That's exactly opposite in my case!  I have two 128M CF cards.
I'm keeping one as a backup.  They have almost exactly the same
contents (1 directory may be different).  I have big files and
small files.  If I can't sync up a big file because it fills the
backup, this patch allows the sync to continue to copy all the
small files.  Without this patch, it was impossible for me to
run rsync on the devices at all: I'd get the "rsync protocol data stream"
errors each time I filled up the destination.

> > rsync.c:	if using -T but not --partial, remove a partial result
> > 		when a write error occurs
> Good idea.  Separate issue i think.

Correct, but using -T is a workaround to the first patch.  If you don't
have the first patch, then -T is the only way to attempt to rsync
between two filesystems that are small/may be near full.  Except that
without the second patch, if you do get a disk full error on the
destination, then you'll never get to proceed to copy the small files.

John