--exclude-from works but "exclude from" in rsyncd.conf doesn't ?

[Wayne Davison]

On Sat, May 10, 2003 at 02:18:02AM -0700, jw schultz wrote:
> You seem to be talking about server-side "exclude" /a/ with a
> command-line location of "server::module/a/b/c" where the whole
> location should be barred.

Yes.  In this case the recursion code never even checks the /a/ dir
since it started scanning down in /a/b/.  I've just fixed this to work
without the extra "- /kludge/**" lines my previous patch required.
It's named the same as before:

    http://www.blorf.net/rsync-daemon-exclude.patch

The fix I chose was to weed out excluded args by matching them a subdir
at a time against the exclude patterns.  The result seems to work great.

> I'm also concerned about a server-side specified "exclude /a/b/c/d/e"
> with a command-line location "server::module/a/b/c".

That was fixed in my first patch.  The fix I chose is to expand all
config-specified values to a fully-qualified path, and to extend the
matching code to prefix relative names with the current directory when
it is compared against these absolute-path match values.  My latest
patch is slightly better than the first one in that it should handle
chroot mode now (though I haven't yet tested that to be sure).

> So far as i can see the lists are not independent.  For downloads the
> client-supplied list seems to be appended to the list from the
> rsyncd.conf file.

Oh yeah, I see what you mean now.  If the server list does an include of
a filename, then the user's exclude of the filename would be ignored in
the appended list.  Drat.  This is even more broken than I thought.

> > Uploads are currently unaffected by the server-side {ex,in}clude
> > restrictions.  I'm planning to look into fixing that as well.
> 
> It looks like a lot of work to get right.

Yeah, looks to be that way.  I think my current patch is a step in the
right direction since it at least plugs the huge, gaping hole in the
exclude list when the server tries to weed out subdirs in a directory
tree.  If the rest proves too complicated, we should at least commit a
fix for this problem (once it has been tested and approved).

..wayne..