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 -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
