#2447 closed defect (fixed)

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

Reported by: zooko Owned by: warner
Priority: normal Milestone: 1.10.2
Component: code-frontend-cli Version: 1.10.0
Keywords: tahoe-cp error Cc: warner
Launchpad Bug:


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

Change History (7)

comment:1 Changed at 2015-06-10T04:07:41Z by 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

My linux box complains with the same error you listed.

comment:2 Changed at 2015-06-10T10:50:10Z by daira

  • Keywords error added
  • Milestone changed from undecided to 1.11.0

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.

comment:3 Changed at 2015-06-15T04:34:39Z by 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.

comment:5 Changed at 2015-07-17T21:52:52Z by daira

  • Milestone changed from 1.11.0 to 1.10.2

comment:6 Changed at 2015-07-21T16:52:54Z by warner

  • Owner set to warner
  • Status changed from new to assigned

comment:7 Changed at 2015-07-29T00:40:37Z by Brian Warner <warner@…>

  • Resolution set to fixed
  • Status changed from assigned to closed

In 98ab848cdae2743753d48dda2c34f081496f7e80/trunk:

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

Closes ticket:2447

Note: See TracTickets for help on using tickets.