--delete-sent-files (AKA --move-files)

[jw schultz]

On Fri, Jan 16, 2004 at 09:30:57PM -0800, Wayne Davison wrote:
> Yes, it's time once again to return to the subject of moving files.
> With the recent changes to the communications code between the receiver
> and the generator, there is now a non-clogging channel that we can use
> to signal the sender when a file has been successfully transferred,
> which allows us delete the original for all transferred files.  I have
> in the past waffled on whether this feature needs to be in rsync.  I'm
> currently back on the side that it's a nice thing to support.  YMMV.
> 
> Here's a new implementation of the feature that adds a generic message
> (MSG_SUCCESS) for the receiver to send back to the sender (through the
> generator).  I made the generator simply forward this message on to the
> sender, but to do that it means that the generator must be in multi-
> plexed IO mode, which it used to be only when it was on the server side.
> My patch adds a new internal flag that lets the code request that the
> generator have messaging capability even when it is on the client side
> (the non-delete-specific variable makes the code more generic).  The one
> not-so-nice thing about this setup is that the sender process gets the
> MSG_SUCCESS for a particular index when it is down in the I/O code, and
> that code doesn't know about the file list.  I decided to make this code
> call a new function, successful_send(), which is back in sender.c.  This
> function is the one that handles translating the index into a file name
> and deleting the source file (assuming that the delete_sent_files flag
> is on, which is currently the only time that MSG_SUCCESS gets sent).  I
> also added a run-time flag to mark the items we sent off to the
> receiver, just to make sure that nothing funny is going on in the
> sequence of events (aside: the sender side has no copy-on-write issues
> to make us avoid tweaking the flags).
> 
> So, feel free to take a look and see if you like what I've done.

I'll leave aside the issue of whether we want a
delete-after.

What you have to underpin the delete-after is almost a
per-file status being communicated.  Long term this would
give us the ability to log at the right point, after it is
actually been completed but done on the local end.  Right
now a push logs the completion when the sender has finished
with the file even if the last bit fails.



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

		Remember Cernan and Schmitt