feedback on rsync-HEAD-20050125-1221GMT

[Chris Shoemaker]

On Fri, Jan 28, 2005 at 11:25:06AM -0500, Alberto Accomazzi wrote:

> 
> Oooh, I see we are getting a little ambitious, aren't we? ;-)
> [suggestion to use 'find' syntax]

If I understand Wayne's design, it would be possible to invent a
(per-directory) "hook" rule, whose value is executed, and whose stdout
is parsed as a [in|ex]clude file list.  E.g.:

 -R "cat .rsync-my-includes"

or

 -R "find . -ctime 1 -a ! -fstype nfs -a ! -empty -o iname 'foo*'"


IMHO, rsync already has too much of its own "filtering" functionality,
and needs less, not more.  But maybe a hook like this that lets users
interface with their own filtering program is a step toward
deprecating rsync's [in|ex]clude[-from] options.

Notice that a generic include and exclude hooks immediately obsoletes
the --*-from options and the --*=PATTERN options.  (rsync needs fewer
options, ya see? :)

> Wayne Davison wrote:
> 
> >It already supports per-directory name rules, both inherited and not.
> >The idea of having per-directory size and time limits would not be hard
> >to add, and may be quite worthwhile.  For instance, assume 's' is for
> >size and 't' is for the modified time:
> >
> >    # Don't transfer files 1 GB or larger
> >    s< 1g
> >    # Don't transfer files 100 KB or smaller
> >    s> 100k
> >    # Only transfer new files (modified in the last day)
> >    t> yesterday
> >
> >Something like that, perhaps.

We don't really want to reinvent 'find', do we?

> One more thing to point out: I got a core dump when starting a daemon 
> which tried to write to a log file that it had no permission to write 
> to.  The problem seems to be that the function log_open in log.c does 
> not check the return value of fopen.  I don't know whether the right 
> thing to do would be to exit with an error or continue but without 
> logging, but something ought to be changed.

Or... simply log to stderr.  After all, user may prevent daemon's
stderr from being redirected to /dev/null.


-chris