`tahoe cp alias1:dir1/fname alias1:dir2/fname .` overwrites one of the files

[zooko]

I just did tahoe cp alias1:dir1/fname alias1:dir2/fname .. It probably should have done something like what unix cp does in this case:

$ cp dir1/fname dir2/fname  .
cp: will not overwrite just-created ‘./fname’ with ‘dir2/fname’

but instead it did this:

$ tahoe cp alias1:dir1/fname alias1:dir2/fname .
Success: files copied

[warner]

The /bin/cp on OS-X 10.10 (which claims "The cp command is expected to be POSIX.2 compatible") silently uses the second copy, just like tahoe currently does:

% mkdir dir1
% echo one >dir1/fname
% mkdir dir2
% echo two >dir2/fname
% cp dir1/fname dir2/fname .
% cat fname
two
%

My linux box complains with the same error you listed.

[daira]

I think the Linux behaviour and error message is confusing -- I don't see how it's better to write the first file than to write the second file.

I think we should instead not write any file, and say in the error message that we haven't done so because there are duplicate filenames.

[warner]

I checked a couple of versions back: tahoe-1.9.0 and 1.10.0 both behave like trunk and OS-X (second file silently wins).

I'm +0 with daira's error-out suggestion for 1.11. I'm -0 for landing this in 1.10.1, just because we're so darn close :). I'm sympathetic to Zooko's argument that prolonging this behavior will increase the number of scripts and tools that accidentally depend upon the unusual (compared to linux, not compared to OS-X) behavior, but I'm also swayed by Daira's argument that it's been this way long enough that one more release isn't going to make much of a difference.

[zooko]

I have a failing unit test for this, yay: ​https://github.com/zooko/tahoe-lafs/commit/26aef8eab2578969a4ec52abd19bbd32537b8bc5

[Brian Warner <warner@…>]

In 98ab848cdae2743753d48dda2c34f081496f7e80/trunk:

cp: error on target-filename collisions, rather than overwrite

Closes ticket:2447