Bug 811746 - cp --attributes-only does not seem to work right
Summary: cp --attributes-only does not seem to work right
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: coreutils
Version: 16
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Ondrej Vasik
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-04-11 20:52 UTC by W. Michael Petullo
Modified: 2012-07-21 02:58 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-07-21 02:58:27 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description W. Michael Petullo 2012-04-11 20:52:22 UTC
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-12 00:40:02 UTC
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-12 01:29:12 UTC
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 10:10:25 UTC
(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 10:37:07 UTC
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 11:18:42 UTC
(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 17:46:00 UTC
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 18:30:48 UTC
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 13:08:23 UTC
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 21:57:41 UTC
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-21 02:58:27 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.