Hello, the bug was observed on Linux this time. Unfortunately I was hit with the bug when backing up several large photo directories with hard-links to one target directory on an external drive. So it was not obvious for me at first, that something was going wrong. From my point of view (without looking at the source) it should be easy to repair by - not attempting to create a hard-link from a file to itself - not deleting a file that is about to be used as the source paramter of a hard-link to be created. best regards Steffen Zahn On Tue, Jun 30, 2015 at 9:02 AM L. A. Walsh wrote: > I think you'll find this was reported 3 years ago.. > > "bug#10471: Severe or critical - deletes existing files and leaves > nothing. (cp)" > https://lists.gnu.org/archive/html/bug-coreutils/2015-04/msg00001.html > > Unfortunately it was closed it out w/the reason that it was a > "cygwin/windows-only" > -- which I disagreed with. I was told the cygwin dev would check it out > and > if it was in coreutils would move it back to active status (that was 3+ > years ago). > > On 6/8/2015 9:18 PM, Steffen Zahn wrote: > > Hello, > > > > I found that the cp command acts "sub-optimal" when copying > > hard-linked files of the same name from several directories to one > > target directory, it first copies the files then removes them. I > > cannot see how that can be the intended behaviour. Please fix this. > > > > best regards > > Steffen Zahn > > > > sz@gandalf:~ $ cd /tmp > > sz@gandalf:/tmp $ mkdir 1 2 3 > > sz@gandalf:/tmp $ touch 1/a > > sz@gandalf:/tmp $ ln 1/a 2/ > > sz@gandalf:/tmp $ ls -li 1 2 > > 1: > > total 0 > > 262424 -rw-r--r-- 2 sz sz 0 Jun 9 06:10 a > > > > 2: > > total 0 > > 262424 -rw-r--r-- 2 sz sz 0 Jun 9 06:10 a > > sz@gandalf:/tmp $ cp -a -u --verbose 1/* 2/* 3/ > > '1/a' -> '3/a' > > removed '3/a' > > cp: cannot create hard link '3/a' to '3/a': No such file or directory > > sz@gandalf:/tmp $ cp --version > > > >