Created attachment 710155 [details] strace output of cp --reflink=always source dest Description of problem: $ stat source File: `source' Size: 172253 Blocks: 344 IO Block: 4096 regular file Device: fd02h/64770d Inode: 1704360 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1002/ydroneaud) Gid: ( 1002/ydroneaud) Access: 2013-03-14 19:05:12.642541940 +0100 Modify: 2013-03-14 19:04:46.787541606 +0100 Change: 2013-03-14 19:04:46.787541606 +0100 Birth: - $ cp --reflink=always source dest cp: failed to clone `dest' from `source': Inappropriate ioctl for device $ stat dest File: `dest' Size: 0 Blocks: 0 IO Block: 4096 regular empty file Device: fd02h/64770d Inode: 1707547 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1002/ydroneaud) Gid: ( 1002/ydroneaud) Access: 2013-03-14 19:07:06.493543407 +0100 Modify: 2013-03-14 19:07:06.493543407 +0100 Change: 2013-03-14 19:07:06.493543407 +0100 Birth: - Expected results: As reflink are not supported on Ext4 filesystem, cp --reflink=always is expected to fail, but it must not create the file, and it must not leave an empty file.
Comment on attachment 710155 [details] strace output of cp --reflink=always source dest MIME Type text/x-log => test/plain
Thanks for the report and suggestion, but this is a bit tricky thing. It is quite common that cp behaves this way in the case of many failures requested by the user. As actual copy process consists from many steps, many such failures end up with an empty destination file. In many cases you don't know if you fail before the attempt, so there is no perfect solution. In this case, I can imagine a check if the reflink is supported by the destination filesystem (or generally by the system, as reflink always fail with ENOTSUP, when __linux__ is not defined). Then cp may exit with error earlier, before actually rewriting the destination file. Still, this is something for upstream discussion.
Some upstream notes on this: http://lists.gnu.org/archive/html/coreutils/2013-03/msg00056.html
Based on the above response of coreutils upstream, closing WONTFIX. Please reiterate the discussion on the upstream mailing-list if necessary.