On 9/26/06, Bill Uhl <[EMAIL PROTECTED]> wrote:
Back in rsync 2.6.2 and before, I used a chmod and ldap patch by Stefan
Nehlsen. The chmod part worked well for me then. As rsync moved on, the
patch no longer worked and my c skills were too limited to figure out
how to update it. I am wondering ab
Back in rsync 2.6.2 and before, I used a chmod and ldap patch by Stefan
Nehlsen. The chmod part worked well for me then. As rsync moved on, the
patch no longer worked and my c skills were too limited to figure out
how to update it. I am wondering about two things.
First. Is the current chmod c
When --perms is off, an incoming chmod of "Dg-s" does not prevent
directories from inheriting setgid bits; it probably should. Incoming
chmod currently takes effect in dest_mode, which is too soon for it to
affect the directory setgid check in set_file_attrs. (It's ironic
that I didn't notice th
On Sat, Sep 23, 2006 at 07:58:05PM -0400, Matt McCutchen wrote:
> Thanks, but what about the changes to acls.diff?
I update patch failures when I'm about to make a new "nightly" tar file,
and I'll do that then.
..wayne..
--
To unsubscribe or change options: https://lists.samba.org/mailman/listin
On 9/23/06, Wayne Davison <[EMAIL PROTECTED]> wrote:
Good catch. I committed your fix and the improved test.
Thanks, but what about the changes to acls.diff? Two hunks failed
when patchsync tried to automatically update my rsync-acl tree.
Matt
--
To unsubscribe or change options: https://lis
On Fri, Sep 22, 2006 at 10:32:44PM -0400, Matt McCutchen wrote:
> The trouble is that tweak_mode (the function that applies chmod
> strings) determines the type of the file it is processing based on the
> type bits of the original mode it is passed, but dest_mode calls it
> with a mode in which the
That seems to work as expected.
Thanks,
Bill Uhl
Matt McCutchen wrote:
Attached is my patch. I rewrote dest_mode and fixed the bug in the
process. I also added a test to chmod-option.test and updated
acls.diff to correctly patch my new dest_mode.
Matt
--
To unsubscribe or change options:
Attached is my patch. I rewrote dest_mode and fixed the bug in the
process. I also added a test to chmod-option.test and updated
acls.diff to correctly patch my new dest_mode.
Matt
### Eclipse Workspace Patch 1.0
#P rsync
Index: rsync.c
==
The trouble is that tweak_mode (the function that applies chmod
strings) determines the type of the file it is processing based on the
type bits of the original mode it is passed, but dest_mode calls it
with a mode in which the type bits are zero when calculating
destination permissions for a file
Paul Slootman wrote:
On Fri 22 Sep 2006, Bill Uhl wrote:
Tried leaving out the repeated D and F per the manpage. Permissions
without the leading D and F were applied to both directories and files.
I am not sure how this would work. Would this make the chmod settings
order speci
On Fri 22 Sep 2006, Bill Uhl wrote:
> Tried leaving out the repeated D and F per the manpage. Permissions
> without the leading D and F were applied to both directories and files.
> I am not sure how this would work. Would this make the chmod settings
> order specific?
I had guessed order-spec
Tried leaving out the repeated D and F per the manpage. Permissions
without the leading D and F were applied to both directories and files.
I am not sure how this would work. Would this make the chmod settings
order specific?
Regarding the filesystem, it's ext3 on an LVM logical volume on a
so
On Fri 22 Sep 2006, Bill Uhl wrote:
>incoming chmod = Dg=s,Dug=rwx,Do-rwx,Fug=rw,Fo-rwx
Following the example in the manpage, I would have used:
incoming chmod = Dg=s,ug=rwx,o-rwx,Fug=rw,Fo-rwx
i.e. leaving out the repeated D and F letters.
> 2006/09/21 04:34:58 [6860] default_per
Running rsync 2.6.8 as daemon on Fedora core 4. Have the following in
the rsyncd.conf file...
[test]
path = /home/test/greenlight
# use chroot = true
max connections = 3
lock file = /var/lock/rsyncd/test.lock
uid = 503
gid = 503
auth users = test
14 matches
Mail list logo
