PATCH: better handling for write failures (disk full)

[jw schultz]

On Thu, May 22, 2003 at 10:37:07AM -0400, John R. LoVerso wrote:
> Here are two patches ("these work for me, YMMV"):

What are they against?  They will probably apply but there
has been considerable change in cvs judging by the
line-numbers.

> receiver.c:	upon a write error, discard the rest of the
> 		current file transfer and keep working. don't give up.
> 		do generate a useful error message.

A useful error message is good.  I'm less certain that we
should proceed.

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.

Perhaps even more important, if one file fails due to a full
filesystem it is likely others will.  What you propose will
result in rsync continuing a broken transfer.  This kind of
stumbling along is likely to progressively fill the
destination where failing tends to back off leaving the
admin some room to maneuver.  If this is accepted there
should be some sort of sanity check like --max-delete
provides on deletes.

> rsync.c:	if using -T but not --partial, remove a partial result
> 		when a write error occurs

Good idea.  Separate issue i think.

> Perhaps the changes in receive_data() could specifically just target
> ENOSPC, on the assumption that any other write error is fatal.
> 
> I'm also using John Van Essen's write_file() patch from:
> 	http://lists.samba.org/pipermail/rsync/2003-April/010511.html

That patch has now been committed.  Thanks for the reminder.