similar to: DO NOT REPLY [Bug 7112] New: --fake-super should use default permissions for real files

rsync --perms -M--fake-super src dst For me, this command means that rsync should save the original perms in the xattr, and leave the real file mode to the umask default. Currently it also modifies the real file mode, and there is no way to store something different in the xattr. According to an old bug report that I found, more people would like --fake-super to be a complete attribute

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

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

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

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

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,

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:

https://bugzilla.samba.org/show_bug.cgi?id=7108 Summary: --fake-super should be nestable Product: rsync Version: 3.1.0 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P3 Component: core AssignedTo: wayned at samba.org ReportedBy: matt at mattmccutchen.net

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

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

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:

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

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

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

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

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

On 05/02/18 05:53, Wayne Davison wrote: > On Sat, Feb 3, 2018 at 5:20 AM, Dave Gordon via rsync > <rsync at lists.samba.org <mailto:rsync at lists.samba.org>> wrote: > > [...fake-super symlink saved as a file...] > > This results in the copy being world-writable. > > Indeed. The file initially gets created as a mode-600 file, but the code > later

Hello everybody. I wrote a small patch in order to support what I think is an absolutely needed feature in order to make rsync-based backups retaining complete ownership permission when writing to an opensolaris machine using --fake-super. My goal is making backups of linux boxes to opensolaris/zfs. In order to make it work just do patch -p1 < patch_file.txt inside rsync source tree. and

Hello trusty rsync list, I'm excited about --fake-super as it will replace too much work with none at all. I have gotten it to work under linux and I have a fair grasp with what is happening there. I have a problem, though, and that is, in the long term, I'll need to archive my Linux systems not to a Linux box, but to a Solaris 10 box. I understand that Solaris does have extended

https://bugzilla.samba.org/show_bug.cgi?id=10496 Summary: --itemize-changes always reports xattr changes with --xattrs --fake-super Product: rsync Version: 3.1.1 Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: P5 Component: core AssignedTo: wayned at