Bug 811746

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.

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.

(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?

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?

(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.

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?

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).

coreutils-8.15-7.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/coreutils-8.15-7.fc17

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).

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.