|--- |FIXED
--- Comment #2 from Wayne Davison ---
I added a comment about --protect-args to the man page.
Most people don't run into this issue because the wild cards are connected to
the mapping option using an equal sign, and most shells pass through unmatched
wildcards with n
https://bugzilla.samba.org/show_bug.cgi?id=10705
--- Comment #1 from Daniel O'Connor 2014-07-10 01:21:17
UTC ---
I looked through the code and found the --protect-args option which does make
--chown work.
I guess it would be difficult to fix unless the wildcard character was changed
to somethin
https://bugzilla.samba.org/show_bug.cgi?id=10705
Summary: usermap/groupmap do not escape wildcards passed to the
remote
Product: rsync
Version: 3.1.1
Platform: All
OS/Version: All
Status: NEW
Severity
>>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
elete
> /home/user from the destination? Is there a workaround for that?
> I'd like to keep the source and destination in sync.
>
> - Grant
>
>
>>>> I'm trying to use wildcards and nested files and I think
>>>> there must be a better way
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 b
t delete /home/user
from the destination? Is there a workaround for that? I'd like to
keep the source and destination in sync.
- Grant
>>> 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 co
> 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 t
ame:
>
> 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:
>
>> /etc /home/*/.maildir
>
>> Is this the
-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
&
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:
/etc
/home/*/.maildir
Is this the best way to do it:
rsync -arzv --delete-excluded --files-from 'files-from.txt'
--i
>>On 01/28/13 17:02, Stewart Jeacocke wrote:
>> I'm trying to copy some directories with rsync and would like to
>> delete files from the destination if they no longer exist in the
>> source.
>>
>> I'm using the following command:
>>
>> rsync -v --archive --hard-links --delete --force
>> --filter='
At 22:02 28.01.2013 +, Stewart Jeacocke wrote:
>Hi,
>
>I'm trying to copy some directories with rsync and would like to
>delete files from the destination if they no longer exist in the
>source.
>
>I'm using the following command:
>
>rsync -v --archive --hard-links --delete --force
>--filter=':
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Is there any output? How about with an additional -v ?
Is there a .rsync-filter file anywhere?
On 01/28/13 17:02, Stewart Jeacocke wrote:
> Hi,
>
> I'm trying to copy some directories with rsync and would like to
> delete files from the destinatio
Hi,
I'm trying to copy some directories with rsync and would like to
delete files from the destination if they no longer exist in the
source.
I'm using the following command:
rsync -v --archive --hard-links --delete --force
--filter=':/.rsync-filter' /opt/ /mnt/backup/opt/
/opt does not contain
$ sudo ls -la /home/*/domains/*
ls: cannot access /home/*/domains/*: No such file or directory
Bash 3.2, Debian Lenny
Hum.
On Friday 29 October 2010 23:02:06 Steven Levine wrote:
> In <201010292152.10643.alexc...@googlemail.com>, on 10/29/10
>
>at 09:52 PM, Alex Cartwright said:
> >Unfortu
In <201010292152.10643.alexc...@googlemail.com>, on 10/29/10
at 09:52 PM, Alex Cartwright said:
>Unfortunately I have tried it without the quotes as well, with no luck.
>$ sudo rsync -arv /home/*/domains/* /home/alex/foo/
>[sudo] password for alex:
could not be transferred (code 23) at main.c(1058)
[sender=3.0.3]
On Friday 29 October 2010 17:16:59 Wayne Davison wrote:
> On Fri, Oct 29, 2010 at 8:00 AM, Alex Cartwright
wrote:
> > rsync -arv '/home/*/domains/*' ~/
>
> That is a local copy, so you're quoting the w
On Fri, Oct 29, 2010 at 8:00 AM, Alex Cartwright wrote:
> rsync -arv '/home/*/domains/*' ~/
>
That is a local copy, so you're quoting the wildcards tells the shell that
they are literal characters in the filename. If you want the shell to do
wildcard expansion, unquote the
Hi there,
We have a directory structure such as:
"/home/foobar/domains/example.com/public"
"/home/cake/domains/mydomain.org/public"
I need to use a single rsync command to sync "/home/*/domains/*" to another
directory, but I'm really struggling on how to do this.
rsync -arv '/home/*/domains/*'
||FIXED
Summary|wildcards and rsync 3.01+ |wildcards and rsync 3.0.1+
--- Comment #2 from [EMAIL PROTECTED] 2008-04-12 00:37 CST ---
Thanks for your report. The attached (trivial) patch fixes this problem.
--
Configure bugmail: https
d
This fixes the problem with wildcards not being expanded in a daemon module
that has chroot enabled.
--
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the QA contact for the bug, or are watching the QA contact.
-
https://bugzilla.samba.org/show_bug.cgi?id=5388
Summary: wildcards and rsync 3.01+
Product: rsync
Version: 3.0.2
Platform: x86
OS/Version: FreeBSD
Status: NEW
Severity: major
Priority: P3
Component: core
On Mon, Nov 10, 2003 at 12:28:39PM -0500, Ian! D. Allen wrote:
> I see from the CVS log that some of the following awkwardness may be
> fixed (or at least different) in the next public release.
Yes, there was quite a bit of bug-fixing in this area for the next
release. The 2 problems you cited we
Rsync version: rsync-2.5.6-3mdk (Mandrake 9.2)
I see from the CVS log that some of the following awkwardness may be
fixed (or at least different) in the next public release. I'm looking
forward to that. In the interim, here are some problems:
-
Problem 1 - unexpected consequence of repl
> 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
Hi,
I'm trying to synchronize some directories.
Let's say I need to synchronize:
/web/sites
/var/qmail/control
/home/ken
I don't want to run 3 rsync commands. I have already tried
using --include --exclude options, but it didn't work at all.
I supppose my command should be as follows:
rsync -a
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
> Hello!
>
> A good day to you all. i would like to know the exact
> syntax for the hosts allow and hosts deny line. The
> documentation states that the standard unix wildcards
> will do , but i have nothad any success when i set
> the ff options:
> hosts allow = 19
Hello!
A good day to you all. i would like to know the exact
syntax for the hosts allow and hosts deny line. The
documentation states that the standard unix wildcards
will do , but i have nothad any success when i set
the ff options:
hosts allow = 192.168.37.*
or
hosts allow = 192.168.37
51 matches
Mail list logo
