>>Is there a rule I can apply to figure out the proper order for includes
>>and excludes?
>
> Rules are evaluated in the order they are defined. The first rule with a
> pattern that that matches is the rule that applies.
That makes sense, thank you for all your help.
- Grant
--
Please use reply
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The way I think of it is that by default everything is included.
Excludes override that and remove certain paaterns. Includes override
that and put back in certain patterns.
On 07/03/13 05:55, Grant wrote:
Anyways, the other way to do what you a
In ,
on 07/03/13
at 01:49 AM, Grant said:
Hi Grant,
>I couldn't agree more. May I suggest that the man page make reference to
>this feature under --include-from and --exclude-from ?
It does, but you have to read the man page from top to bottom. As with
all man pages, there's a trade off be
In ,
on 07/03/13
at 02:55 AM, Grant said:
Hi Grant,
>Is there a rule I can apply to figure out the proper order for includes
>and excludes?
Rules are evaluated in the order they are defined. The first rule with a
pattern that that matches is the rule that applies.
If you are a C programmer
>>> Anyways, the other way to do what you are asking is: rsync -azvi
>>> --exclude-from=excludes.txt --delete --delete-excluded /
>>> user@hostname:
>>>
>>> excludes.txt: + / + /etc + /etc/** + /home + /home/*/ +
>>> /home/*/.maildir/ + /home/*/.maildir/** - - *
>>
>> So the includes are in exclude
>>> These are both specializations of the generic --filter='merge filters.txt'
>>> filter option. See the rsync man page for the gory details.
>
>> That's a great feature and I think it should be referenced in some way
>> under --include-from and --exclude-from in man rsync.
>
> This is almost alr
Hi
On Wed, 03 Jul 2013 11:00:38 +0200 Grant wrote:
>> These are both specializations of the generic --filter='merge filters.txt'
>> filter option. See the rsync man page for the gory details.
> That's a great feature and I think it should be referenced in some way
> under --include-from and --e
>>> rsync -azvi --exclude-from=excludes.txt --delete --delete-excluded /
>>> user@hostname:
>
>>> excludes.txt:
>>> + /
>>> + /etc
>>> + /etc/**
>>> + /home
>>> + /home/*/
>>> + /home/*/.maildir/
>>> + /home/*/.maildir/**
>>> - - *
>
>>So the includes are in excludes.txt prefixed with "+ " and the
>>> Anyways, the other way to do what you are asking is: rsync -azvi
>>> --exclude-from=excludes.txt --delete --delete-excluded /
>>> user@hostname:
>>>
>>> excludes.txt: + / + /etc + /etc/** + /home + /home/*/ +
>>> /home/*/.maildir/ + /home/*/.maildir/** - - *
>>
>> So the includes are in exclude
In ,
on 07/02/13
at 12:25 PM, Grant said:
Hi,
>> rsync -azvi --exclude-from=excludes.txt --delete --delete-excluded /
>> user@hostname:
>> excludes.txt:
>> + /
>> + /etc
>> + /etc/**
>> + /home
>> + /home/*/
>> + /home/*/.maildir/
>> + /home/*/.maildir/**
>> - - *
>So the includes are in e
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/02/13 15:25, Grant wrote:
>> Anyways, the other way to do what you are asking is: rsync -azvi
>> --exclude-from=excludes.txt --delete --delete-excluded /
>> user@hostname:
>>
>> excludes.txt: + / + /etc + /etc/** + /home + /home/*/ +
>> /home/*
> Anyways, the other way to do what you are asking is:
> rsync -azvi --exclude-from=excludes.txt --delete --delete-excluded /
> user@hostname:
>
> excludes.txt:
> + /
> + /etc
> + /etc/**
> + /home
> + /home/*/
> + /home/*/.maildir/
> + /home/*/.maildir/**
> - - *
So the includes are in excludes.t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
No, that is a consequence of using a * on the command line. The shell
would expand "/home/*/.maildir" to a list of all matching paths. When
you delete a user their /home/username will no longer exist so that
pattern will no longer match and their dir
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --files-from is a specific list of files to sync. It is designed with
the idea of being generated by find.
Anyways, the other way to do what you are asking is:
rsync -azvi --exclude-from=excludes.txt --delete --delete-excluded /
user@hostname:
exc
> I forgot the --delete. Also, note that it will not delete an entire
> account that you have deleted from the source as /home/* will no
> longer match them.
You're saying if I rsync /home/user and then delete /home/user from
the source and rsync again with --delete, it won't delete /home/user
fr
> rsync -aRzv /etc /home/*/.maildir rsyncuser@hostname:
I'd actually like to use --files-from so it's easier to manage and
--files-from doesn't support wildcards. That's why it gets so messy.
- Grant
>> I'm trying to use wildcards and nested files and I think there must
>> be a better way than
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I forgot the --delete. Also, note that it will not delete an entire
account that you have deleted from the source as /home/* will no
longer match them.
On 07/02/13 12:29, Kevin Korb wrote:
> rsync -aRzv /etc /home/*/.maildir rsyncuser@hostname:
>
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
rsync -aRzv /etc /home/*/.maildir rsyncuser@hostname:
On 07/02/13 08:17, Grant wrote:
> I'm trying to use wildcards and nested files and I think there must
> be a better way than what I'm doing. If I want to copy only these
> two directories:
>
> /e
> On Mon, Mar 17, 2003 at 04:5929PM +0100, Wayne wrote:
> > Let's say I need to synchronize:
> >
> > /web/sites
> > /var/qmail/control
> > /home/ken
>
> If your command is that simple, you should just list all the dirs on the
> commandline without any include/exclude stuff and use -R (--relative)
On Mon, Mar 17, 2003 at 04:06:29PM +0100, Ken wrote:
> Let's say I need to synchronize:
>
> /web/sites
> /var/qmail/control
> /home/ken
If your command is that simple, you should just list all the dirs on the
commandline without any include/exclude stuff and use -R (--relative):
rsync -azvlR /we
Here's a more complex version of the wildcard change that attempts to
count slashes in the pattern (if it does not contain "**" anywhere) and
to match at the appropriate level.
In trying to think up patterns where this might mess up, the only thing
I thought of was something like this:
foo/
On Mon, 13 May 2002, Dave Dykstra wrote:
> I suggest you go ahead and code it in the way you
> think would be simplest and then we can evaluate it more concretely.
OK. Here's the simple patch. It optimizes the loop away if the pattern
starts with "**" (since the loop would be superfluous), but
On Fri, May 10, 2002 at 11:35:24AM -0700, Wayne Davison wrote:
> On Fri, 10 May 2002, Dave Dykstra wrote:
> > If you dynamically created a */*/*/foo/* pattern with the number of */
> > to match the current path it would only have to call fnmatch once.
>
> That's assuming the pattern doesn't conta
On Fri, 10 May 2002, Dave Dykstra wrote:
> If you dynamically created a */*/*/foo/* pattern with the number of */
> to match the current path it would only have to call fnmatch once.
That's assuming the pattern doesn't contain an interior/trailing "**"
(which could only use the try-after-each-sla
On Thu, May 09, 2002 at 05:42:41PM -0700, Wayne Davison wrote:
> On Thu, 9 May 2002, Dave Dykstra wrote:
> > How many times would you have to call fnmatch for every file?
>
> We'd call fnmatch() an extra time for every slash in the path. However,
> the performance hit of this new loop on the pat
On Thu, 9 May 2002, Dave Dykstra wrote:
> How many times would you have to call fnmatch for every file?
We'd call fnmatch() an extra time for every slash in the path. However,
the performance hit of this new loop on the pattern "foo/*" would be the
same as using the two patterns "/**/foo/*" & "/
On Thu, May 09, 2002 at 02:32:59PM -0700, Wayne Davison wrote:
> On Thu, 9 May 2002, Dave Dykstra wrote:
> > I would say it's definitely too risky for 2.5.6.
>
> What would you say to adding a (simple) loop to the fnmatch() code that
> would cause unanchored things like "foo/*/bar" to not be boun
On Thu, 9 May 2002, Wayne Davison wrote:
> What would you say to adding a (simple) loop to the fnmatch() code that
Just to clarify (since the above is poorly worded) -- I meant adding the
loop to the rsync code that calls fnmatch(), not trying to modify the
fnmatch() code directly.
..wayne..
-
On Thu, 9 May 2002, Dave Dykstra wrote:
> I would say it's definitely too risky for 2.5.6.
What would you say to adding a (simple) loop to the fnmatch() code that
would cause unanchored things like "foo/*/bar" to not be bound to the
start of the filename? This would make it work in an equivalent
Well the modified wildmat certainly looks simpler but I think it's going to
be awfully hard to test for all the kinds of cases rsync is likely to run
into. I don't have time to look at it very closely, but I would say it's
definitely too risky for 2.5.6. The fact that it is based on previously
t
30 matches
Mail list logo
