Red Hat Bugzilla – Full Text Bug Listing
|Summary:||cp --attributes-only does not seem to work right|
|Product:||[Fedora] Fedora||Reporter:||W. Michael Petullo <mike>|
|Component:||coreutils||Assignee:||Ondrej Vasik <ovasik>|
|Status:||CLOSED ERRATA||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||16||CC:||kdudka, maxamillion, ovasik, p, twaugh|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2012-07-20 22:58:27 EDT||Type:||Bug|
|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.