Displaying 20 results from an estimated 8000 matches similar to: "Would you expect --perms -M--fake-super to set the file mode to the original one?"
2020 Mar 12
2
Would you expect --perms -M--fake-super to set the file mode to the original one?
Thank you for the feedback, I'm glad to see that different people see the
issue
differently. As a followup question, what would you expect this to do:
rsync --perms --chmod g+rX -M--fake-super src dst
I would expect it to store the original permissions in the xattr, while
modifying the real file mode according to the chmod.
On Thursday, March 12, 2020 6:06:34 PM CET, Kevin Korb via rsync
2020 Mar 16
2
Would you expect --perms -M--fake-super to set the file mode to the original one?
Thanks. This is a bit counter-intuitive to me. So how would you tell
rsync to store the original permissions in the xattr, but do not touch
the real file mode?
On Thursday, March 12, 2020 6:26:18 PM CET, Kevin Korb via rsync wrote:
> I would expect that the sending rsync would only send the perms provided
> modified by the --chmod. I wouldn't expect the receiver to even know
> the
2020 Mar 12
0
Would you expect --perms -M--fake-super to set the file mode to the original one?
Permissions don't require super. Any place where permissions can't be
stored certainly can't handle xattrs either. So, I wouldn't expect
--fake-super to affect --perms at all.
On 3/12/20 12:46 PM, Dimitrios Apostolou via rsync wrote:
> rsync --perms -M--fake-super src dst
>
> For me, this command means that rsync should save the original perms in the
> xattr, and
2020 Mar 12
0
Would you expect --perms -M--fake-super to set the file mode to the original one?
I would expect that the sending rsync would only send the perms provided
modified by the --chmod. I wouldn't expect the receiver to even know
the other permissions.
On 3/12/20 1:23 PM, Dimitrios Apostolou via rsync wrote:
> Thank you for the feedback, I'm glad to see that different people see
> the issue
> differently. As a followup question, what would you expect this to do:
2020 Mar 16
0
Would you expect --perms -M--fake-super to set the file mode to the original one?
I don't believe it is possible. I think the misunderstanding stems from
the fact that the permissions are even stored in the xattr. They don't
need to be there but they may as well be. They don't take much space.
The real question would be when rsync reads the file to restore it and
the file perms are different than the ones in the xattr which set does
it use?
On 3/16/20 10:01 AM,
2010 Feb 08
1
DO NOT REPLY [Bug 7112] New: --fake-super should use default permissions for real files
https://bugzilla.samba.org/show_bug.cgi?id=7112
Summary: --fake-super should use default permissions for real
files
Product: rsync
Version: 3.1.0
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P3
Component: core
AssignedTo: wayned at samba.org
2019 Dec 09
2
How Can I save the original permissions while setting g+rX for all files
Hello list!
Combining -M--fake-super with --chmod ends up changing the permissions
stored in the fake-super xattrs. I.e. the permissions stored in the xattr,
are
affected by --chmod.
The desirable behaviour for me would be for --chmod to modify the real
permissions of the destination files. The use case is writing a backup as a
non-root user, having it readable by the group (g+rX), while also
2020 Mar 17
1
[RFC PATCH] Add SHA1 support
On 2020-03-17 00:03:03 [+0100], Dimitrios Apostolou via rsync wrote:
> On Thursday, February 20, 2020 10:34:53 PM CET, Sebastian Andrzej Siewior
> via rsync wrote:
> >
> > I'm still not sure if rsync requires a cryptographic hash _or_ if a
> > strong hash like xxHash64 would be just fine for the job.
>
> I'm fairly sure the hash should *not* be easy to
2020 Feb 20
2
[RFC PATCH] Add SHA1 support
On 2020-02-20 20:06:39 [+0100], Markus Ueberall wrote:
> On 2020-02-09 23:19, Sebastian Andrzej Siewior wrote:
> > [...]
> > My primar motivation to use SHA1 for checksumming (by default) instead
> > of MD5 is not the additional security bits but performance. On a decent
> > x86 box the SHA1 performance is almost the same as MD5's but with
> > acceleration it
2010 Jan 27
6
DO NOT REPLY [Bug 7070] New: Permission denied message with --fake-super and permissionless directory
https://bugzilla.samba.org/show_bug.cgi?id=7070
Summary: Permission denied message with --fake-super and
permissionless directory
Product: rsync
Version: 3.0.6
Platform: x86
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P3
Component: core
AssignedTo: wayned at
2002 May 10
1
Preserve TARGET perms, user and group would be nice
Using --existing, I would like to transfer files created by root to home
dirs, where the files would be updated, but leave the user,group and perms
as they were. ie root creates a new file on the sending system, rsyncs it
to the home dir of the user, leaving the perms untouched.
Seems there is no option for this - the users are not defined on the
sending system. I cant do it backwards due to
2019 Dec 09
0
How Can I save the original permissions while setting g+rX for all files
When I try it the chmod works on both the real permissions and the
permissions in the xatttr. Maybe the behavior has changed since
whatever version you have (3.1.3 here) but this probably wouldn't help
you either.
On 12/8/19 7:56 PM, Dimitrios Apostolou via rsync wrote:
> Hello list!
>
> Combining -M--fake-super with --chmod ends up changing the permissions
> stored in the
2007 Nov 15
2
2.6.9 w/ acl, xattr, and fake-super support?
Hello,
As i cannot get 3.0.0pre5 to work in my environment (throwing crazy
errors which i've posted previously), i would like to revert to 2.6.9 .
Of course, the reason i tried to use v3 in the first place was for the
acl, xattr, and fake-super options - which, evidently, can be enabled
under 2.6.9, as per the following sources:
http://lists.samba.org/archive/rsync/2007-February/017218.html
2017 Jun 05
1
[Bug 12820] New: rsync always try change owner and group of symlink in --fake-super mode
https://bugzilla.samba.org/show_bug.cgi?id=12820
Bug ID: 12820
Summary: rsync always try change owner and group of symlink in
--fake-super mode
Product: rsync
Version: 3.0.9
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P5
Component: core
2013 Jan 24
2
[Bug 9594] New: Error transferring user and non-user xattr using --fake-super under Linux
https://bugzilla.samba.org/show_bug.cgi?id=9594
Summary: Error transferring user and non-user xattr using
--fake-super under Linux
Product: rsync
Version: 3.1.0
Platform: All
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P5
Component: core
AssignedTo: wayned at
2007 Aug 04
1
Why does --xattrs imply --perms?
Why does --xattrs imply --perms (according to the man page)? Unlike
--acls, --xattrs is not logically a superset of --perms (since
system.* xattrs are ignored). I might conceivably want to copy some
user xattrs that I set on my files while allowing the destination
permissions to take the default value.
Matt
2010 Feb 08
1
DO NOT REPLY [Bug 7110] New: Symlink fake-super data is silently lost when sys_lsetxattr fails with EPERM
https://bugzilla.samba.org/show_bug.cgi?id=7110
Summary: Symlink fake-super data is silently lost when
sys_lsetxattr fails with EPERM
Product: rsync
Version: 3.1.0
Platform: All
OS/Version: All
Status: NEW
Severity: major
Priority: P3
Component: core
AssignedTo: wayned at
2008 Mar 02
2
DO NOT REPLY [Bug 5298] New: xattrs and acls do not work well together along with fake-super, even worse on XFS
https://bugzilla.samba.org/show_bug.cgi?id=5298
Summary: xattrs and acls do not work well together along with
fake-super, even worse on XFS
Product: rsync
Version: 3.0.0
Platform: x86
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P3
Component: core
AssignedTo:
2003 Mar 01
3
Samba and LinuxMDK 9 file perms oddities?
Hi all
I noticed a pretty strange behaviour regarding file permissions that
sometimes change without any reason. I need to share the following two
directories:
/home/public (owner=root, group=root, perms=0777)
/home/users (owner=root, group=users, perms=0770)
the /home directory is owned by root, the group is root and permissions
are set in this way: 0755.
The above dirs are shared
2009 Nov 25
3
Acl Groups
Hi all!
I have a corpus of virtual users ( user1 at domain.tld , user2 at domain.tld,
user3 at domain.tld,..., usern at domain.tld ... ) authenticated
against Active Directory.
Is it possible to group some users (virtual) and give appropriate ACLs
on a shared imap public folder using an ACL vfile?
thanks in advance
Dimitrios