tahoe cp alias1:dir1/fname alias1:dir2/fname .
overwrites one of the files #2447
Labels
No Label
0.2.0
0.3.0
0.4.0
0.5.0
0.5.1
0.6.0
0.6.1
0.7.0
0.8.0
0.9.0
1.0.0
1.1.0
1.10.0
1.10.1
1.10.2
1.10a2
1.11.0
1.12.0
1.12.1
1.13.0
1.14.0
1.15.0
1.15.1
1.2.0
1.3.0
1.4.1
1.5.0
1.6.0
1.6.1
1.7.0
1.7.1
1.7β
1.8.0
1.8.1
1.8.2
1.8.3
1.8β
1.9.0
1.9.0-s3branch
1.9.0a1
1.9.0a2
1.9.0b1
1.9.1
1.9.2
1.9.2a1
LeastAuthority.com automation
blocker
cannot reproduce
cloud-branch
code
code-dirnodes
code-encoding
code-frontend
code-frontend-cli
code-frontend-ftp-sftp
code-frontend-magic-folder
code-frontend-web
code-mutable
code-network
code-nodeadmin
code-peerselection
code-storage
contrib
critical
defect
dev-infrastructure
documentation
duplicate
enhancement
fixed
invalid
major
minor
n/a
normal
operational
packaging
somebody else's problem
supercritical
task
trivial
unknown
was already fixed
website
wontfix
worksforme
No Milestone
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Reference: tahoe-lafs/trac-2024-07-25#2447
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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:but instead it did this:
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:
My linux box complains with the same error you listed.
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.
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.
I have a failing unit test for this, yay: https://github.com/zooko/tahoe-lafs/commit/26aef8eab2578969a4ec52abd19bbd32537b8bc5
In /tahoe-lafs/trac-2024-07-25/commit/98ab848cdae2743753d48dda2c34f081496f7e80: