[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [rdiff-backup-users] include/exclude options
From: |
Ben Escoto |
Subject: |
Re: [rdiff-backup-users] include/exclude options |
Date: |
Sun, 30 May 2004 21:06:43 -0400 |
>>>>> Duke <address@hidden>
>>>>> wrote the following on Mon, 24 May 2004 15:24:53 -0400
> Am I the only one who finds the include/exclude options a little
> confusing?
No, apparently not. But personally I think the --include/--exclude is
pretty intuitive, relatively speaking.
> Why is the behaviour between --include/exclude so much different from
> --include/exclude-filelist?
> I don't understand how the above command worked so well, yet when I
> specify a list of directories in a file and use the following command:
If you want the same behavior as --include/--exclude in a file list,
use --include-globbing-filelist/--exclude-globbing-filelist, as David
Kempe mentioned.
The reason there is two options for filelists is because I thought
people would want to specify files using "find" or something similar.
So suppose you used, for instance:
find foo -maxdepth 2 | rdiff-backup --include-filelist-stdin foo bar
intending to back up only the directories two deep. This would not
work as intended if filelists and commandline excludes worked the same
way: find would produce some directory "foo/subdir", and then
rdiff-backup would back up everything under subdir.
Another reason is that when processing command line arguments
rdiff-backup reorders and sorts the includes/excludes. When
processing a filelist, I think rdiff-backup assumes that it's in order
and processes the list lazily. This is so you don't have to generate
the complete filelist all at once.
I forget now, but there are a number of issues considered and I'm
generally satisfied with the usability of the admittedly complex
system.
Just remember to use --*-globbing-* if you are producing the filelists
by hand.
> Only the directories I specified (and not their contents) are backed
> up.
That is supposed to be a feature (see explanation above).
--
Ben Escoto