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

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