On 11/25/10 22:51:36, Renat Golubchyk wrote: > On Tue, 16 Nov 2010 23:01:51 +0000 Mick <michaelkintz...@gmail.com> > wrote: > > On Tuesday 16 November 2010 22:26:28 Stefan G. Weichinger wrote: > > > Am 2010-11-16 22:24, schrieb Alan McKinnon: > > > > Apparently, though unproven, at 23:12 on Tuesday 16 November > > > > 2010, Mick did > > > > > > > > opine thusly: > > > >> Excellent, it worked! :-) > > > > > > > > Glad to hear it. > > > > > > > > I could help because part of my job is running a rather big > > > > public ftp mirror that management graciously pay for. And I > went > > > > down this rsync road a long time ago myself. > > > > > > > > You have no idea how many brain cells died in agony to figure > out > > > > this specific piece of rsync behaviour :-) > > > > > > ;-) > > > > > > I would like to know if my suggestion also works ;-) > > > > > > Yeah, include/exclude-patterns are rather hard to figure out > > > sometimes ... nearly like regexes -> write once, read never .... > > > > Ha, ha! True! > > > > Stefan, I tried escaping the spaces (even tried \\ double and \\\ > > triple escapes in case it makes a difference because of using ssh) > > but still did not work. In my head I couldn't see how the full > path > > would not work, but the relative path would, but I tried it out all > > the same. > > > > I still don't understand why Alan's recommendation works ;-) > > I'm probably late with my reply, but I'll post it so it will be in > the > archives for future reference. > > The man page is actually pretty clear on this issue. Quote: > > if the pattern starts with a / then it is anchored to a particular > spot in the hierarchy of files, otherwise it is matched against > the > end of the pathname. This is similar to a leading ^ in regular > expressions. Thus "/foo" would match a name of "foo" at either the > "root of the transfer" (for a global rule) or in the merge-file’s > directory (for a per-directory rule). An unqualified "foo" > would > match a name of "foo" anywhere in the tree because the algorithm > is > applied recursively from the top down; it behaves as if each path > component gets a turn at being the end of the filename. Even the > unanchored "sub/foo" would match at any point in the hierarchy > where a "foo" was found within a directory named "sub". > > "Root of the transfer" is the directory you want to sync. Thus, if > you > run e.g. "rsync /var/log/ /mnt/backups/ --exclude=/portage/" then > root > of the transfer is /var/log, and therefore the directory > /var/log/portage will be excluded. If on the other hand you write > --exclude=portage/ then a directory named portage anywhere in the > tree > under /var/log will be excluded. Without the trailing slash, i.e. > just > --exclude=portage any file (regular file, directory, link, whatever) > named portage anywhere in the tree gets excluded. And finally > --exclude=/portage would exclude a file only at the top of the tree > that > is going to be synchronsed. >
Let me add some caveat which has trapped me recently. I had (in your terms) rsync /var/log/ /mnt/backups/ --delete --exclude=/portage/ and /var/log/portage was just a symlink to some other directory while /mnt/backups/portage was a real directory. In that case rsync deletes /mnt/backups/portage ! It looks as if the "directory property" is check in the source tree only. Quite an unpleasant surprise. Helmut.