GNU bug report logs -
#5775
[PATCH] doc: fix info to say cp -a does _not_ diagnose xattr failures
Previous Next
Reported by: Pádraig Brady <P <at> draigBrady.com>
Date: Fri, 26 Mar 2010 12:07:02 UTC
Severity: normal
Tags: patch
Done: Jim Meyering <jim <at> meyering.net>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 5775 in the body.
You can then email your comments to 5775 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
owner <at> debbugs.gnu.org, bug-coreutils <at> gnu.org:
bug#5775; Package
coreutils.
(Fri, 26 Mar 2010 12:07:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Pádraig Brady <P <at> draigBrady.com>:
New bug report received and forwarded. Copy sent to
bug-coreutils <at> gnu.org.
(Fri, 26 Mar 2010 12:07:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
I was surprised that `cp --preserve=all file.xattr /dev/shm` produced no warnings
In any case, this makes the docs match the behaviour.
cheers,
Pádraig.
From 67d915612c56f8a33f24305ed84eda2a8918080a Mon Sep 17 00:00:00 2001
From: =?utf-8?q?P=C3=A1draig=20Brady?= <P <at> draigBrady.com>
Date: Fri, 26 Mar 2010 11:19:16 +0000
Subject: [PATCH] doc: fix info to say cp -a does _not_ diagnose xattr failures
The info docs have been inaccurate since 2009-04-17, commit 941bd482,
"mv: ignore xattr-preservation failure when not supported by filesystem"
* doc/coreutils.texi (cp invocation): Say that cp --preserve=all
does _not_ output errors when failing to copy xattrs.
---
doc/coreutils.texi | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index e7c09c5..2a5f4d4 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -7344,7 +7344,7 @@ directory structure; i.e., @samp{ls -U} may list the entries in a copied
directory in a different order).
Try to preserve SELinux security context and extended attributes (xattr),
but ignore any failure to do that and print no corresponding diagnostic.
-Equivalent to @option{-dR --preserve=all} with the reduced diagnostics.
+Equivalent to @option{-dR --preserve=all}.
@item -b
@itemx @w{@kbd{--backup}[=@var{method}]}
@@ -7518,8 +7518,7 @@ they are preserved by this option as well.
Preserve all file attributes.
Equivalent to specifying all of the above, but with the difference
that failure to preserve SELinux security context or extended attributes
-does not change @command{cp}'s exit status.
-@command{cp} does diagnose such failures.
+does not change @command{cp}'s exit status, or produce error messages.
@end table
Using @option{--preserve} with no @var{attribute_list} is equivalent
--
1.6.2.5
Information forwarded
to
owner <at> debbugs.gnu.org, bug-coreutils <at> gnu.org:
bug#5775; Package
coreutils.
(Fri, 26 Mar 2010 13:02:01 GMT)
Full text and
rfc822 format available.
Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):
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.
From the log of the change you quote, it's obvious this is the right change.
Thanks!
> Subject: [PATCH] doc: fix info to say cp -a does _not_ diagnose xattr failures
>
> The info docs have been inaccurate since 2009-04-17, commit 941bd482,
> "mv: ignore xattr-preservation failure when not supported by filesystem"
> * doc/coreutils.texi (cp invocation): Say that cp --preserve=all
> does _not_ output errors when failing to copy xattrs.
bug marked as fixed in version 5782, send any further explanations to Pádraig Brady <P <at> draigBrady.com>
Request was from
Jim Meyering <jim <at> meyering.net>
to
control <at> debbugs.gnu.org.
(Mon, 29 Mar 2010 08:03:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-coreutils <at> gnu.org:
bug#5775; Package
coreutils.
(Fri, 09 Apr 2010 23:54:01 GMT)
Full text and
rfc822 format available.
Message #13 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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.
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?
cheers,
Pádraig.
[standard-diagnostics.diff (text/x-patch, attachment)]
Information forwarded
to
owner <at> debbugs.gnu.org, bug-coreutils <at> gnu.org:
bug#5775; Package
coreutils.
(Sun, 11 Apr 2010 13:38:02 GMT)
Full text and
rfc822 format available.
Message #16 received at submit <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-coreutils <at> gnu.org:
bug#5775; Package
coreutils.
(Sun, 11 Apr 2010 15:19:02 GMT)
Full text and
rfc822 format available.
Message #19 received at submit <at> debbugs.gnu.org (full text, mbox):
On 11/04/10 14:37, Jim Meyering wrote:
> 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.
I can see the tradeoff, but the result is currently confusing.
For example with /dev/shm (tmpfs) on my Fedora system I can preserve
security.selinux and system.posix_acl_access xattrs but
not security.capability or user.*. That's confusing and inconsistent
in itself, but when combined with ENOTSUP special casing from cp/mv
one really doesn't know what's going on.
In other words we shouldn't make any assumptions about what the
user might expect of a file system. We really can just print
error messages if they need the particular attribute preserved
and keep quiet otherwise.
Hrm I just noticed that you only get an error to copy context
when the file already exists (so fsetfilecon is used rather
than setfscreatecon)
$ sudo ./src/cp --preserve=context file vfat/
$ sudo ./src/cp --preserve=context file vfat/
./src/cp: failed to set the security context of `vfat/file' to
`system_u:object_r:user_home_t:s0': Operation not supported
Note `install` does an unlink() rather than open(O_TRUNC)
and so will not show an error
$ sudo ./src/ginstall --preserve-context file vfat/
$ sudo ./src/ginstall --preserve-context file vfat/
I also notice that install.c never sets require_preserve_context=true
which seems to contradict the description of --preserve-context,
though the point is somewhat moot due to fsetfilecon not
being called in any case.
cheers,
Pádraig.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-coreutils <at> gnu.org:
bug#5775; Package
coreutils.
(Sun, 11 Apr 2010 15:50:02 GMT)
Full text and
rfc822 format available.
Message #22 received at submit <at> debbugs.gnu.org (full text, mbox):
Pádraig Brady wrote:
> On 11/04/10 14:37, Jim Meyering wrote:
>> 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.
>
> I can see the tradeoff, but the result is currently confusing.
> For example with /dev/shm (tmpfs) on my Fedora system I can preserve
> security.selinux and system.posix_acl_access xattrs but
> not security.capability or user.*. That's confusing and inconsistent
> in itself, but when combined with ENOTSUP special casing from cp/mv
> one really doesn't know what's going on.
> In other words we shouldn't make any assumptions about what the
> user might expect of a file system. We really can just print
> error messages if they need the particular attribute preserved
> and keep quiet otherwise.
>
> Hrm I just noticed that you only get an error to copy context
> when the file already exists (so fsetfilecon is used rather
> than setfscreatecon)
>
> $ sudo ./src/cp --preserve=context file vfat/
> $ sudo ./src/cp --preserve=context file vfat/
> ./src/cp: failed to set the security context of `vfat/file' to
> `system_u:object_r:user_home_t:s0': Operation not supported
>
> Note `install` does an unlink() rather than open(O_TRUNC)
> and so will not show an error
>
> $ sudo ./src/ginstall --preserve-context file vfat/
> $ sudo ./src/ginstall --preserve-context file vfat/
>
> I also notice that install.c never sets require_preserve_context=true
> which seems to contradict the description of --preserve-context,
> though the point is somewhat moot due to fsetfilecon not
> being called in any case.
I agree that the current state is unsatisfying.
If you can find a way to improve things without
making commonly used options (cp -a, mv) produce
new warnings, I'm all for it.
Could it be that you want a new option (groan, maybe...)
to remove all of this diagnostic-suppressing behavior?
Information forwarded
to
owner <at> debbugs.gnu.org, bug-coreutils <at> gnu.org:
bug#5775; Package
coreutils.
(Sun, 11 Apr 2010 16:00:03 GMT)
Full text and
rfc822 format available.
Message #25 received at submit <at> debbugs.gnu.org (full text, mbox):
On 11/04/10 16:47, Jim Meyering wrote:
> Pádraig Brady wrote:
>> On 11/04/10 14:37, Jim Meyering wrote:
>>> 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.
>>
>> I can see the tradeoff, but the result is currently confusing.
>> For example with /dev/shm (tmpfs) on my Fedora system I can preserve
>> security.selinux and system.posix_acl_access xattrs but
>> not security.capability or user.*. That's confusing and inconsistent
>> in itself, but when combined with ENOTSUP special casing from cp/mv
>> one really doesn't know what's going on.
>> In other words we shouldn't make any assumptions about what the
>> user might expect of a file system. We really can just print
>> error messages if they need the particular attribute preserved
>> and keep quiet otherwise.
>>
>> Hrm I just noticed that you only get an error to copy context
>> when the file already exists (so fsetfilecon is used rather
>> than setfscreatecon)
>>
>> $ sudo ./src/cp --preserve=context file vfat/
>> $ sudo ./src/cp --preserve=context file vfat/
>> ./src/cp: failed to set the security context of `vfat/file' to
>> `system_u:object_r:user_home_t:s0': Operation not supported
>>
>> Note `install` does an unlink() rather than open(O_TRUNC)
>> and so will not show an error
>>
>> $ sudo ./src/ginstall --preserve-context file vfat/
>> $ sudo ./src/ginstall --preserve-context file vfat/
>>
>> I also notice that install.c never sets require_preserve_context=true
>> which seems to contradict the description of --preserve-context,
>> though the point is somewhat moot due to fsetfilecon not
>> being called in any case.
>
> I agree that the current state is unsatisfying.
> If you can find a way to improve things without
> making commonly used options (cp -a, mv) produce
> new warnings, I'm all for it.
Well the patch _reduces_ warnings so that they're only
shown in case 3 above. They should probably also
be output in case 5 also which currently doesn't happen
as explained above.
> Could it be that you want a new option (groan, maybe...)
> to remove all of this diagnostic-suppressing behavior?
Well I had thought of that. I.E. output all
errors in cases 1,2,4 when --warnings is on.
There is the --verbose option but that also has
the side effect of outputting non warning text.
But the current situation is better than having
a new option I think.
cheers,
Pádraig.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-coreutils <at> gnu.org:
bug#5775; Package
coreutils.
(Sun, 11 Apr 2010 18:32:01 GMT)
Full text and
rfc822 format available.
Message #28 received at submit <at> debbugs.gnu.org (full text, mbox):
Pádraig Brady wrote:
...
> Well the patch _reduces_ warnings so that they're only
> shown in case 3 above. They should probably also
> be output in case 5 also which currently doesn't happen
> as explained above.
Yes, but I'm convinced that those warnings have some
value at least some of the time, so I'm very leery of
suppressing them, even if the rules for when they're
emitted are inconsistent and hard to describe.
>> Could it be that you want a new option (groan, maybe...)
>> to remove all of this diagnostic-suppressing behavior?
>
> Well I had thought of that. I.E. output all
> errors in cases 1,2,4 when --warnings is on.
> There is the --verbose option but that also has
> the side effect of outputting non warning text.
> But the current situation is better than having
> a new option I think.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-coreutils <at> gnu.org:
bug#5775; Package
coreutils.
(Mon, 12 Apr 2010 11:09:02 GMT)
Full text and
rfc822 format available.
Message #31 received at submit <at> debbugs.gnu.org (full text, mbox):
On 11/04/10 19:31, Jim Meyering wrote:
> Pádraig Brady wrote:
> ...
>> Well the patch _reduces_ warnings so that they're only
>> shown in case 3 above. They should probably also
>> be output in case 5 also which currently doesn't happen
>> as explained above.
>
> Yes, but I'm convinced that those warnings have some
> value at least some of the time, so I'm very leery of
> suppressing them, even if the rules for when they're
> emitted are inconsistent and hard to describe.
OK fair enough, I'll push this doc clarification soon
which attempts to better describe what's happening.
cheers,
Pádraig.
commit c420cfef77b9173a754806dc49deacabb436044f
Author: Pádraig Brady <P <at> draigBrady.com>
Date: Mon Apr 12 08:46:37 2010 +0100
doc: clarify when cp and mv output xattr warnings
The 2010-03-26 commit, 4c38625e, "doc: fix info on cp --preserve..."
was not entirely correct as cp --preserve=all does produce some
xattr warnings.
* src/copy.h: Update and clarify the comments for reduce_diagnostics
and require_preserve_{xattr,context}.
* doc/coreutils.texi (cp invocation): Update the -a and
--preserve=xattr,context options to say when and which
xattr warnings are output.
(mv invocation): Mention that some warnings are output
when preserving xattrs.
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index f549989..7561f2a 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -7344,7 +7344,7 @@ directory structure; i.e., @samp{ls -U} may list the entries in a copied
directory in a different order).
Try to preserve SELinux security context and extended attributes (xattr),
but ignore any failure to do that and print no corresponding diagnostic.
-Equivalent to @option{-dR --preserve=all}.
+Equivalent to @option{-dR --preserve=all} with the reduced diagnostics.
@item -b
@itemx @w{@kbd{--backup}[=@var{method}]}
@@ -7507,18 +7507,18 @@ $ mkdir b c; (cd b; : > a; ln -s a b); cp -aL b c; ls -i1 c/b
@end smallexample
@itemx context
-Preserve SELinux security context of the file. @command{cp} will fail
-if the preserving of SELinux security context is not succesful.
+Preserve SELinux security context of the file, or fail with full diagnostics.
@itemx xattr
-Preserve extended attributes if @command{cp} is built with xattr support,
-and xattrs are supported and enabled on your file system.
+Preserve extended attributes of the file, or fail with full diagnostics.
+If @command{cp} is built without xattr support, ignore this option.
If SELinux context, ACLs or Capabilities are implemented using xattrs,
they are preserved by this option as well.
@itemx all
Preserve all file attributes.
Equivalent to specifying all of the above, but with the difference
that failure to preserve SELinux security context or extended attributes
-does not change @command{cp}'s exit status, or produce error messages.
+does not change @command{cp}'s exit status. In contrast to @option{-a},
+all but @samp{Operation not supported} warnings are output.
@end table
Using @option{--preserve} with no @var{attribute_list} is equivalent
@@ -8276,6 +8276,7 @@ original partition.
@cindex extended attributes, xattr
@command{mv} always tries to copy extended attributes (xattr), which may
include SELinux context, ACLs or Capabilities.
+Upon failure all but @samp{Operation not supported} warnings are output.
@cindex prompting, and @command{mv}
If a destination file exists but is normally
diff --git a/src/copy.h b/src/copy.h
index bd7359f..59e29f5 100644
--- a/src/copy.h
+++ b/src/copy.h
@@ -180,15 +180,13 @@ struct cp_options
Set this only if the kernel is SELinux enabled. */
bool preserve_security_context;
- /* Useful only when preserve_security_context is true.
- If true, a failed attempt to preserve a file's security context
- propagates failure "out" to the caller. If false, a failure to
- preserve a file's security context does not change the invoking
- application's exit status. Give diagnostics for failed syscalls
- regardless of this setting. For example, with "cp --preserve=context"
- this flag is "true", while with "cp -a", it is false. That means
- "cp -a" attempts to preserve any security context, but does not
- fail if it is unable to do so. */
+ /* Useful only when preserve_context is true.
+ If true, a failed attempt to preserve file's security context
+ propagates failure "out" to the caller, along with full diagnostics.
+ If false, a failure to preserve file's security context does not
+ change the invoking application's exit status, but may output diagnostics.
+ For example, with `cp --preserve=context` this flag is "true",
+ while with `cp --preserve=all` or `cp -a`, it is "false". */
bool require_preserve_context;
/* If true, attempt to preserve extended attributes using libattr.
@@ -197,16 +195,19 @@ struct cp_options
/* Useful only when preserve_xattr is true.
If true, a failed attempt to preserve file's extended attributes
- propagates failure "out" to the caller. If false, a failure to
- preserve file's extended attributes does not change the invoking
- application's exit status. Give diagnostics for failed syscalls
- regardless of this setting. For example, with "cp --preserve=xattr"
- this flag is "true", while with "cp --preserve=all", it is false. */
+ propagates failure "out" to the caller, along with full diagnostics.
+ If false, a failure to preserve file's extended attributes does not
+ change the invoking application's exit status, but may output diagnostics.
+ For example, with `cp --preserve=xattr` this flag is "true",
+ while with `cp --preserve=all` or `cp -a`, it is "false". */
bool require_preserve_xattr;
- /* Used as difference boolean between cp -a and cp -dR --preserve=all.
- If true, non-mandatory failure diagnostics are not displayed. This
- should prevent poluting cp -a output.
+ /* This allows us to output warnings in cases 2 and 4 below,
+ while being quiet for case 1 (when reduce_diagnostics is true).
+ 1. cp -a try to copy xattrs with no errors
+ 2. cp --preserve=all copy xattrs with all but ENOTSUP warnings
+ 3. cp --preserve=xattr,context copy xattrs with all errors
+ 4. mv copy xattrs with all but ENOTSUP warnings
*/
bool reduce_diagnostics;
Information forwarded
to
owner <at> debbugs.gnu.org, bug-coreutils <at> gnu.org:
bug#5775; Package
coreutils.
(Mon, 12 Apr 2010 11:24:02 GMT)
Full text and
rfc822 format available.
Message #34 received at submit <at> debbugs.gnu.org (full text, mbox):
Pádraig Brady wrote:
> On 11/04/10 19:31, Jim Meyering wrote:
>> Pádraig Brady wrote:
>> ...
>>> Well the patch _reduces_ warnings so that they're only
>>> shown in case 3 above. They should probably also
>>> be output in case 5 also which currently doesn't happen
>>> as explained above.
>>
>> Yes, but I'm convinced that those warnings have some
>> value at least some of the time, so I'm very leery of
>> suppressing them, even if the rules for when they're
>> emitted are inconsistent and hard to describe.
>
> OK fair enough, I'll push this doc clarification soon
> which attempts to better describe what's happening.
...
> commit c420cfef77b9173a754806dc49deacabb436044f
> Author: Pádraig Brady <P <at> draigBrady.com>
> Date: Mon Apr 12 08:46:37 2010 +0100
>
> doc: clarify when cp and mv output xattr warnings
>
> The 2010-03-26 commit, 4c38625e, "doc: fix info on cp --preserve..."
> was not entirely correct as cp --preserve=all does produce some
> xattr warnings.
>
> * src/copy.h: Update and clarify the comments for reduce_diagnostics
> and require_preserve_{xattr,context}.
> * doc/coreutils.texi (cp invocation): Update the -a and
> --preserve=xattr,context options to say when and which
> xattr warnings are output.
> (mv invocation): Mention that some warnings are output
> when preserving xattrs.
Nice work. Thank you.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Tue, 11 May 2010 11:24:03 GMT)
Full text and
rfc822 format available.
This bug report was last modified 15 years and 46 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.