Bug 811746

Summary: cp --attributes-only does not seem to work right
Product: [Fedora] Fedora Reporter: W. Michael Petullo <mike>
Component: coreutilsAssignee: Ondrej Vasik <ovasik>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 16CC: kdudka, maxamillion, ovasik, p, twaugh
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-07-20 22:58:27 EDT Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

Description W. Michael Petullo 2012-04-11 16:52:22 EDT
Description of problem:
cp --attributes-only ... seems to cause an existing destination file to be overwritten with an empty file. As far as I can tell, this is not the intended behavior for this feature.

Version-Release number of selected component (if applicable):
coreutils-8.12-6.fc16.x86_64

How reproducible:
Every time

Steps to Reproduce:
$ sudo cp /etc/passwd .
$ ls -l passwd 
-rw-r--r--. 1 user group 1897 Apr 11 15:47 passwd
$ sudo cp --attributes-only /etc/passwd passwd 
$ ls -l passwd 
-rw-r--r--. 1 user group 0 Apr 11 15:47 passwd
  
Actual results:
See how the second "ls -l" displays that the size of passwd is 0?

Expected results:
I thought --attributes-only would avoid changing the file's contents.

Additional info:
Comment 1 Pádraig Brady 2012-04-11 20:40:02 EDT
Hmm, well I intended that option to be like a normal copy,
except that the data copy was skipped. I.E. the truncate
of existing files is maintained. The use case I was thinking of was:
http://www.pixelbeat.org/docs/unix_file_replacement.html

So to summarize existing operations:

1. copy attr + data           => cp --preserve=all file1 file2
2. copy attr to empty file    => cp --attributes-only file1 file2
3. copy attr to existing file => currently not supported

However the use case at the link above is still supported
if you didn't truncate the destination, so I guess it's
more flexible to switch the last 2 operations,
though we can't just switch as people may be relying on the
truncating behavior.

A related request in this area is http://debbugs.gnu.org/8370

I'm not sure how best to support/specify operation 3. in cp now.
We should at least document this better upstream.
Comment 2 W. Michael Petullo 2012-04-11 21:29:12 EDT
Okay, comment #1 makes sense. I agree that what needs to change is the documentation. I read the man page before making the report (and even read the debbugs report you cite), and it never occured to me that --attributes-only should truncate files. Now that I read your description, I realize that the work flow I presented in the original report is backwards; I should copy the attributes before the file, not vice versa.

I feel that more precise documentation would be sufficient.
Comment 3 Kamil Dudka 2012-04-12 06:10:25 EDT
(In reply to comment #1)
> 2. copy attr to empty file    => cp --attributes-only file1 file2

This is contra-intuitive.  Changing the documentation does not change the fact that the option name itself is misleading.

> A related request in this area is http://debbugs.gnu.org/8370

I hit this ticket yesterday when searching for an explanation, but I did not understand the request, neither the reply.

    "cp --attributes-only is great for preserving all metadata attributes
     without corrupting contents, but ..."

Is that ^^^ true?
Comment 4 Pádraig Brady 2012-04-12 06:37:07 EDT
I agree it's a bit confusing :(

In retrospect non truncating is probably the more flexible behavior,
though as I said, I'd be wary of changing now.

TBH, I don't fully understand Eric's request and
what he means by "without corrupting contents".
He may have also though it didn't truncate?
Comment 5 Kamil Dudka 2012-04-12 07:18:42 EDT
(In reply to comment #4)
> In retrospect non truncating is probably the more flexible behavior,
> though as I said, I'd be wary of changing now.

IMHO, it would be better to deprecate the --attribute-only option and replace it by --create-empty, --attr-to-empty, or something like that ... or, as you said, to implement the more generic semantics, perhaps as a new option to avoid a change in behavior?
 
> TBH, I don't fully understand Eric's request and
> what he means by "without corrupting contents".
> He may have also though it didn't truncate?

I think so.  I was unable to decide whether the here reported behavior was intended or buggy ... and reading the ticket did not help me to clarify it.
Comment 6 Pádraig Brady 2012-04-12 13:46:00 EDT
After discussion upstream it was agreed to avoid this truncating behavior.
The patch to do that is:

http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commit;h=3d53e7fe

I'm thinking it would be nice to have that applied.
For F17 anyway?
Comment 7 Ondrej Vasik 2012-04-12 14:30:48 EDT
Yep, it makes sense to apply that to f16/f17 in next coreutils update (I'll probably do more fixes in one update as usually).
Comment 8 Fedora Update System 2012-07-13 09:08:23 EDT
coreutils-8.15-7.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/coreutils-8.15-7.fc17
Comment 9 Fedora Update System 2012-07-14 17:57:41 EDT
Package coreutils-8.15-7.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing coreutils-8.15-7.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-10642/coreutils-8.15-7.fc17
then log in and leave karma (feedback).
Comment 10 Fedora Update System 2012-07-20 22:58:27 EDT
coreutils-8.15-7.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.