move-file support

[jw schultz]

On Thu, May 08, 2003 at 12:56:31PM -0700, Wayne Davison wrote:
> I'd like some opinions on a couple of long-standing rsync issues.  My
> two oldest, uncommitted patches are:
> 
>   - A "no hang" patch that makes sure that the pipe from the receiver
>     to the generator can't block with resend requests.
> 
>   - The "move files" patch that got changed into a --delete-sent-files
>     option.
> 
> For each item I have two questions -- do we need to deal with this?
> And is the proposed change a good way to implement the change?  Some
> comments on each item follow:
> 
> Move-File Support
> =================
> 
> I'm currently debating with myself whether I believe that rsync should
> get a --delete-sent-files option.  If you think of rsync as a "keeping
> things in sync" program, removing a file after transferring it seems to
> be a little outside the realm of rsync's purpose.  However, if you think
> of rsync as a feature-rich and more bandwidth-efficient copy tool, then
> having the ability to move files between machines as well as copy them
> seems like an appropriate addition.  I certainly need to be able to move
> files between systems at my work, and I haven't seen a better tool for
> this than rsync with one of my old move-files patches applied to it.
> I'd love to hear what people think about this issue.

Reviewing the paragraph below i find i am thinking in type (like
out-loud only with a keyboard).

Well, i think of rsync as a "keep trees in sync" tool
modeled on cp.  Where cp's semantics apply they should be
used.  If you want a swiss army chainsaw use perl :)   Using
rsync as a network mv utility is almost contradictory to the
sync aspect buuUUuut a network mv is semi-consistant with
the cp model.  I could go either way.

> Implementing this is interesting.  The best way to do it is for the
> receiver to send a success message back to the sender so that it can
> remove the source file only when it has been successfully sent.  One
> implementation was to use the redo channel for this ack, and that means
> that the above no-hang patch would need to be implemented first.  An
> untried implementation would be to use the error channel (from the
> receiver through the generator to the sender) as a way to send the
> sender a "delete item X" message.
> 
> An alternate approach that is conceptually simpler is to add a file-
> removal pass on the sending side at the end of the transfer, but I have
> grown more doubtful over time that this method would properly handle
> error conditions in a reasonable manner (since we want to avoid both
> erasing a file that didn't get sent and leaving a file unremoved that
> did get sent).

Even if a move-file mode weren't implimented i still like
the ACK very much.  One of rsync's greatest weaknesses is
the way it handles errors.  We really have no positive
confirmation of successful transfers.  We know an error
occured if the error channel makes a report but can still
have reported the file as successfully sent.  With an ACK
we could defer reporting (--verbose) the file as sent until
we have the ACK.  No assumptions.  If the ACK/NACK indicated
type of failure (mismatched checksums, write-error, EACCESS)
that would be even better.

What kind of latency has the redo (perhaps renamed status)
channel?  This really should be a structured transmission
sending file number and status flags, not a text stream.

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

		Remember Cernan and Schmitt