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

Previous Next

Package: coreutils;

Reported by: Gael Donval <gael.donval <at> manchester.ac.uk>

Date: Thu, 29 May 2025 05:04:02 UTC

Severity: normal

Full log


View this message in rfc822 format

From: Pádraig Brady <P <at> draigBrady.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Gael Donval <gael.donval <at> manchester.ac.uk>, 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:18:43 +0100
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.

cheers,
Pádraig




This bug report was last modified 13 days ago.

Previous Next


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