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: Pádraig Brady <P <at> draigBrady.com>
To: Gael Donval <gael.donval <at> manchester.ac.uk>, "eggert <at> cs.ucla.edu" <eggert <at> cs.ucla.edu>
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 14:31:44 +0100

On 04/06/2025 12:55, Gael Donval wrote:
>> 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.

Oh right, I missed that sorry.
I'll hold off so on --preserve=xattr-supported.

> `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.
So you're suggesting supporting something like --xattrs-include=... and --xattrs-exclude.
Looking now, I see that tar supports those exact options.
Also rsync support xattr filtering though its --filter rules.
This does give more control, though also less general control
as one would need to config the xattrs for each particular system / call.
Also given other archiving tools support this already,
I'm not sure it's warranted in cp.

cheers,
Pádraig

Previous Next

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