GNU bug report logs - #5775
[PATCH] doc: fix info to say cp -a does _not_ diagnose xattr failures

Previous Next

Full log

Message #16 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: Ondřej Vaš, Report bugs to <bug-coreutils <at> gnu.org>,
	ík <ovasik <at> redhat.com>
Subject: Re: bug#5775: [PATCH] doc: fix info to say cp -a does _not_ diagnose
	xattr failures
Date: Sun, 11 Apr 2010 15:37:29 +0200

Pádraig Brady wrote:
> On 26/03/10 11:53, Pádraig Brady wrote:
>> I was surprised that `cp --preserve=all file.xattr /dev/shm` produced no warnings
>> In any case, this makes the docs match the behaviour.
>
> Actually some warnings could be output in this case so my patch is incorrect.
> The xattr/selinux diagnostics from cp/mv/install are done like:
>
> 1. cp -a			outputs no warnings
> 2. cp --preserve=all		outputs all but ENOTSUP
> 3. cp --preserve=xattr,context	outputs all errors
> 4. mv				outputs all but ENOTSUP
> 5. install --preserve-context	outputs all but ENOTSUP
>
> I'm not sure about treating xattr errors differently
> to other attribute preservation errors, and in
> addition ENOTSUP differently from other errors.
> It just seems a bit inconsistent to me.

It's a delicate balance.
We try very hard not to suppress diagnostics that may indicate a failure.
However, when adding xattr/selinux support we could not afford to change
legacy behavior of cp -a (and mv): reporting all failure-to-preserve
errors would have made cp -a inundate many users with irrelevant-to-them
errors.  When copying to e.g., NTFS or FAT, you should expect SELinux
attributes not to be copied, and warning about that expected failure
would just annoy people and risk burying legitimate errors.

> So how about simplifying the code to match the doc change.
> I.E. don't output any warnings for 2,4 & 5 above.
> A diff to do that is attached:
>  copy.c    |   63 ++++++++++++++++----------------------------------------------
>  copy.h    |   32 +++++++++++--------------------
>  cp.c      |    2 -
>  install.c |    1
>  mv.c      |    1
>  5 files changed, 29 insertions(+), 70 deletions(-)
>
> Alternatively we could make 1 behave like 2,4,5?

As suggested above, I'm afraid that would make cp -a too verbose.

Previous Next

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