I like to get ideas on excluding/including based on user or group id. Right now I'm syncing from local to remote: find show/season/episode/ -type f -and \( -uid 621 -or -uid 540 -or -uid 517 -or -uid 539 \) > /tmp/rsyncCron /root/rsync/rsync -za -h --stats --numeric-ids --files-from=/tmp/rsyncCron --relative ./ rsync://remote/root/ and then to sync from remote site to local /root/rsync/rsync --delete --exclude-from=/tmp/rsyncCron --exclude='/shot/*/maya/*' -za --stats -h --numeric-ids rsync://remote/root/Shows/show/season/episode/ /mnt/root/Shows/show/season/episode/ However this runs the risk of any files created locally during the length of the first rsync being deleted. I've read through exclude.c and by passing the STAT_STRUCT around instead of just the file path, it would be pretty easy to add exclude flags for UID, GID, size, mtime, etc. Is this a reasonable approach? Thanks!
On Wed, Mar 28, 2007 at 07:19:58PM -0700, Barry Robison wrote:> However this runs the risk of any files created locally during the > length of the first rsync being deleted.For a two-way sync, the "unison" tool is usually a better solution. Or, adding a saved list a files with rsync lets the tool notice if a file is new or deleted by its absense or presence in the list. One such script (that uses rsync) is on the resources page of the web site (drsync).> I've read through exclude.c and by passing the STAT_STRUCT around > instead of just the file path, it would be pretty easy to add exclude > flags for UID, GID, size, mtime, etc. Is this a reasonable approach?I'm hesitant to add that to the regular distribution, but if you work up your own custom version, I might include a patch for the feature in the distribution. ..wayne..