On 12/07/2012 09:43 PM, Florian Pritz wrote:
Hi,
I've used the following code in an update script. I don't want cp to
change permission since the target directory has default ACLs in place
that will set the correct permissions, but I want to keep timestamps so
once upon a time I added "--preserve=timestamp
--nopreserve=mode,ownership". I've tested without mode now and it seems
permission are fine.
mkdir a
touch a/a
cp -rfT --preserve=timestamps --no-preserve=mode,ownership a b
If I remove mode from the arguments to --no-preserve it exits 0, but if
you have it it exits 1 and doesn't print anything. It worked in
coreutils 8.19 (exit code 0) even though it might not actually do
anything. If it's intended behaviour you should at least print some kind
of error message.
The cause of this change is commit
24ebca61a3a0f10d6cd2800b188b3c034d1c4755 but it doesn't say anything
about changing the exit code.
Thanks for the report.
Outch, yes, unlike in other places, return_val is set to false
unconditionally in copy_reg():
+ else if (x->explicit_no_preserve_mode)
+ {
+ set_acl (dst_name, dest_desc, 0666 & ~cached_umask ());
+ return_val = false;
+ }
And furthermore, the test preserve-mode.sh which would have
detected this error, don't check cp's exit code ;-(
Here's a proposed patch.