GNU bug report logs - #78623
cp --preserve=xattr copies attr as well as xattr which breaks cross-FS copy

Previous Next

Full log

View this message in rfc822 format

From: Gael Donval <gael.donval <at> manchester.ac.uk>
To: "eggert <at> cs.ucla.edu" <eggert <at> cs.ucla.edu>, "P <at> draigBrady.com" <P <at> draigBrady.com>
Cc: "78623 <at> debbugs.gnu.org" <78623 <at> debbugs.gnu.org>
Subject: bug#78623: cp --preserve=xattr copies attr as well as xattr which breaks cross-FS copy
Date: Wed, 4 Jun 2025 11:55:36 +0000

> On 30/05/2025 18:16, Paul Eggert wrote:
> > On 2025-05-30 02:37, Pádraig Brady wrote:
> > > we only have this issue with --preserve=xattr which diagnoses any
> > > issues.
> > > Perhaps we would benefit from a --preserve=supported-xattr option?
> > 
> > If we go that route, it might be a bit better if the new option-arg
> > began with 'xattr' rather than ended with 'xattr' so that it's easier to
> > find in the doc. Perhaps something like --preserve='xattr-try'?
> > 
> > I'm not quite seeing the motivation, though. Why are scripts using
> > --preserve=xattr rather than the much-simpler '-a'? That is, why
> > preserve xattr but not other metadata?
> 
> Thinking a bit more about this I think I'll add it, because:
> 
> 1. ENOTSUP is common with xattrs
> 
> 2. `--preserve=all --no-preserve=mode,ownership,timestamps,links,context`
> is too verbose, and not future proof if we ever add another --preserve option.
> 
> 3. It's more descriptive to explicitly say that -a implies --preserve=xattr-supported
> 
> I would also like to get feedback though on why -a doesn't suffice.
> Though I suppose by that argument you could ask why we need the
> various --preserve options at all.

I'm not sure whether you have received my previous message (#32 on the
bug tracker). Just in case: we use cp to copy full OS trees and need
the diagnostic to determine when intermediaries break xattrs.

`cp -a` offers that flexibility (good) but also silently drops
everything if any intermediary does not support xattrs (very bad). The
latter is relatively common on distributed FS but could also happen
depending on vendor/admin choices.


The current approach of setting up xattr copy rules in /etc/xattr.conf
is unwieldy: 

1. it does not work for non-root users;
2. and does not allow for any call-specific adjustment.

Setting up a container so that a normal user can setup a scoped local
/etc/xattr.conf tailored to their use, to make a specific tree copy
checking for the existence of a minimal set of supported xattrs is a
bit convoluted. 

Any alternative suggestion would be good.

Thanks,
Gaël

> 
> cheers,
> Pádraig

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.