similar to: Why does --xattrs imply --perms?

Does rsync support acl and xattr (as with acl and user_xattr mount options)? I saw some acl patches for rsync, so probably it's not officially blessed yet. However, I didn't see any xattr patches - although some talks about it on the list go back into year 2003. So how it is with support for these? If I backup a Samba server, which has a filesystem mounted with acl,user_xattr (with

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

I noticed that rsync sometimes miscalculates the permissions of the top-level destination directory when --perms is off. For example, run these commands in an area free of default ACLs: umask 0000 mkdir -p src/foo chmod 700 src src/foo rsync -r src/ dest/ find . -ls 763054 0 drwx------ 4 matt matt 96 Feb 16 17:57 . 763158 0 drwx------ 3 matt matt 72 Feb 16

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

On 6/30/07, Wayne Davison <wayned@samba.org> committed: > Added Files: > checksum-xattr.diff > Log Message: > A simple patch that lets rsync use cached checksum values stored in > each file's extended attributes. A perl script is provided to create > and update the values. Wayne, You should be aware of two drawbacks of caching checksums in xattrs: First,

https://bugzilla.samba.org/show_bug.cgi?id=8201 Summary: rsync 3.0.8 destroys SELinux security context of symbolic links Product: rsync Version: 3.0.8 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: core AssignedTo: wayned at samba.org

I see that rsync will eventually support extended attributes, which will be great. But: will it allow backup from a file system that supports xattrs, to one that does not? For this to work, rsync would have to represent the xattrs on the destination machine in some special format, I suppose, which is outside the usual rsync mode of operation. Moreover, even if both machines support

I wrote a patch for rsync 2.6.6 that changes two things: (1) When the receiving rsync creates a file in a directory with a default ACL and `--perms' is off, rsync uses the default ACL instead of the umask to calculate the new file's permissions. All programs that just use `open' and don't do an explicit `chmod' are forward-compatible with default ACLs, but rsync always sets

I recently found a bug in the xattrs patch, where it would apply the wrong xattrs to some files in a transfer. While looking at the code, I think I found another one (it sure looks wrong, but I haven't figured out how to demonstrate it yet). Anyway, here's the patch: The first hunk fixes the apparent bug. The second hunk fixes the demonstratable bug. I haven't (yet) looked to see

Greetings Group! I hope this will be an easy one. To conserve steps in backing up the metadata extended attributes of a Lustre mdt, I am looking at using a newer version of tar combined with its --xattrs option. (Note: Previously I have used the mdt two-step back-up from the Lustre Manual and it has been successful.) If I can backup the extended attributes via tar so that I don''t

On Fri, Mar 24, 2023 at 9:26?AM Roberto Sassu <roberto.sassu at huaweicloud.com> wrote: > > On Fri, 2023-03-24 at 11:18 +0100, Roberto Sassu wrote: > > On Thu, 2023-03-23 at 20:09 -0400, Paul Moore wrote: > > > On Tue, Mar 14, 2023 at 4:19?AM Roberto Sassu > > > <roberto.sassu at huaweicloud.com> wrote: > > > > From: Roberto Sassu

On Fri, 2023-03-24 at 17:39 -0400, Paul Moore wrote: > On Fri, Mar 24, 2023 at 9:26?AM Roberto Sassu > <roberto.sassu at huaweicloud.com> wrote: > > On Fri, 2023-03-24 at 11:18 +0100, Roberto Sassu wrote: > > > On Thu, 2023-03-23 at 20:09 -0400, Paul Moore wrote: > > > > On Tue, Mar 14, 2023 at 4:19?AM Roberto Sassu > > > > <roberto.sassu at

The security.evm extended attribute is fully owned by the Linux kernel and cannot be directly written from userspace. Therefore, we can always skip it. --- xattrs.c | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/xattrs.c b/xattrs.c index b105392..3b72e61 100644 --- a/xattrs.c +++ b/xattrs.c @@ -255,6 +255,9 @@ static int rsync_xal_get(const char *fname,

Add additional arguments for tar, so extended attributes and/or SELinux contexts can be saved in output tars. --- daemon/tar.c | 18 +++++++++++++----- generator/actions.ml | 10 +++++++++- 2 files changed, 22 insertions(+), 6 deletions(-) diff --git a/daemon/tar.c b/daemon/tar.c index d6f8f2f..68af749 100644 --- a/daemon/tar.c +++ b/daemon/tar.c @@ -311,7 +311,7 @@

https://bugzilla.samba.org/show_bug.cgi?id=13241 Bug ID: 13241 Summary: A problem with test for xattrs transfer Product: rsync Version: 3.1.2 Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P5 Component: core Assignee: wayned at samba.org Reporter:

Hi all, I'm new to the rsync list. I've been searching for two days and have tried five different installs and so far none work the way I need them to. I have an "backup" server running rsync --version: rsync version 2.6.6 protocol version 29 Copyright (C) 1996-2005 by Andrew Tridgell and others <http://rsync.samba.org/> Capabilities: 64-bit files, socketpairs, hard

On 01/06/2017 12:27 AM, L. A. Walsh wrote: > Stefan Berger wrote: >> The security.evm extended attribute is fully owned by the Linux kernel >> and cannot be directly written from userspace. Therefore, we can always >> skip it. > --- (see below "...")... > > Please put this on a switch or option. > > The security.evm field seems only special on

On Fri, Mar 24, 2023 at 6:18?AM Roberto Sassu <roberto.sassu at huaweicloud.com> wrote: > On Thu, 2023-03-23 at 20:09 -0400, Paul Moore wrote: > > On Tue, Mar 14, 2023 at 4:19?AM Roberto Sassu > > <roberto.sassu at huaweicloud.com> wrote: > > > From: Roberto Sassu <roberto.sassu at huawei.com> > > > > > > Currently,

Hello. On May 22, someone reported that xattrs don't work right with --link-dest on rsync 3.0.0cvs: http://lists.samba.org/archive/rsync/2007-May/017768.html I've run into the same problem, but on Red Hat Enterprise Linux 5: # rsync --version rsync version 2.6.8 protocol version 29 Copyright (C) 1996-2006 by Andrew Tridgell, Wayne Davison, and others. <http://rsync.samba.org/>