specifying a list of files to transfer

[Lee Eakin]

I like it (except for the work).  I don't think I'm ready to code up a
filter yet, but it is good to know the general theory in case I need to use
it.  Of course, if I keep thinking about it I'll probably run across a
situation where it's use would greatly speed/simplify my life, so maybe I
should go ahead and throw something together ;).

Yes, the filter would need to sit in the middle for the duration of the
xfer, but I am thinking of those situations where the tree scan is very
costly so the little overhead and complexity of the filter would be worth
it.

  -Lee

---begin quoted text---
> From: Wayne Davison <wayned at users.sourceforge.net>
> Date: Wed, 15 Jan 2003 13:34:08 -0800
> 
> On Wed, Jan 15, 2003 at 02:48:05PM -0600, Lee Eakin wrote:
> > Now if I can only figure out a way to intercept the list when I need to
> > be real picky about which individual files are accessed ...
> 
> This should be possible with a filter process.  Here's how the new,
> slightly tweaked protocol works:
> 
> 1. The normal startup exchange occurs up to the point just before where
>    the (normal) file info (names + attributes) starts to flow from the
>    sender to the receiver.
> 
> 2a At this point IFF the sender is the remote process (i.e. we're
>    pulling files), the receiver begins to send file names (separated by
>    either newlines or nulls, as indicated by the --null option) over the
>    socket (normally there is no data being sent to the sender during
>    this stage).  The end of the list is marked by an empty entry.  (Note
>    that the receiver begins receiving file info from the sender during
>    this stage, so it must do both things at once without blocking.)  If
>    the recursive flag is set, the receiver may get more names back than
>    it sends out.
> 
> 2b Alternately, if the sender is the local process, the normal file info
>    transfer happens (without anything new occurring over the socket).
> 
> 3. The rest of the transfer proceeds as normal.
> 
> So, if a filter understood the protocol enough to be able to pass
> through all the initial rsync data, it could actually look at all the
> names that go over the wire and allow/disallow/tweak them however it
> desired.  (It's sad that this filter would then have to continue to
> relay all the data over the socket after its work was done, but that's
> the price you pay.)  You'd just have to look for the --null option on
> the command-line to know if you're looking for a newline or a null EOL
> character, and stop scanning at the first empty name.
> 
> Alternately, you could just disallow the --files-from option and not
> worry about authorizing the data.
---end quoted text---

-- 
    Lee Eakin - leakin at dfw.nostrum.com
 
Lynch's Law:
  When the going gets tough, everybody leaves.