Inconsistent 'tahoe cp' behavior

[markberger]

When copying a file from the top level of a directory node using the CLI, tahoe requires a file name to be specified.

Ex: tahoe cp tahoe:Seattle.jpg ~ fails with the following assertion traceback, while tahoe cp tahoe:Seattle.jpg ~/Seattle.jpg succeeds.

Marks-MacBook-Pro-5:tahoe-fork markberger$ bin/tahoe cp tahoe:Seattle.jpg ~
Traceback (most recent call last):
  File "/Users/markberger/Code/tahoe-fork/src/allmydata/scripts/runner.py", line 156, in run
    rc = runner(sys.argv[1:], install_node_control=install_node_control)
  File "/Users/markberger/Code/tahoe-fork/src/allmydata/scripts/runner.py", line 141, in runner
    rc = cli.dispatch[command](so)
  File "/Users/markberger/Code/tahoe-fork/src/allmydata/scripts/cli.py", line 551, in cp
    rc = tahoe_cp.copy(options)
  File "/Users/markberger/Code/tahoe-fork/src/allmydata/scripts/tahoe_cp.py", line 770, in copy
    return Copier().do_copy(options)
  File "/Users/markberger/Code/tahoe-fork/src/allmydata/scripts/tahoe_cp.py", line 451, in do_copy
    status = self.try_copy()
  File "/Users/markberger/Code/tahoe-fork/src/allmydata/scripts/tahoe_cp.py", line 512, in try_copy
    return self.copy_to_directory(sources, target)
  File "/Users/markberger/Code/tahoe-fork/src/allmydata/scripts/tahoe_cp.py", line 672, in copy_to_directory
    self.copy_files_to_target(self.targetmap[target], target)
  File "/Users/markberger/Code/tahoe-fork/src/allmydata/scripts/tahoe_cp.py", line 703, in copy_files_to_target
    self.copy_file_into(source, name, target)
  File "/Users/markberger/Code/tahoe-fork/src/allmydata/scripts/tahoe_cp.py", line 748, in copy_file_into
    target.put_file(name, f)
  File "/Users/markberger/Code/tahoe-fork/src/allmydata/scripts/tahoe_cp.py", line 156, in put_file
    precondition(isinstance(name, unicode), name)
  File "/Users/markberger/Code/tahoe-fork/src/allmydata/util/assertutil.py", line 39, in precondition
    raise AssertionError, "".join(msgbuf)
AssertionError: precondition: 'Seattle.jpg' <type 'str'>

However, when a file is copied from a subdirectory to the local disk without a specified file name, the download will succeed.

Ex: tahoe cp tahoe:test/Seattle.jpg ~ succeeds along with tahoe cp tahoe:test/Seattle.jpg ~/Seattle.jpg.

All four cases should succeed.

[daira]

All four cases in the description should succeed.

[markberger]

Here is my branch for this ticket: ​https://github.com/markberger/tahoe-lafs/tree/2027-inconsistent-tahoe-cp

[markberger]

On my branch there is a test for this ticket and a patch that solves this issue.

[daira]

We discussed this ticket on the Dev Chat, and concluded that it needed more work because the Unicode coercion is in the wrong place (it should be moved up in the call stack, at least to the caller of copy_files_to_target).

[daira]

Reviewing.

[daira]

#2029 was merged into this ticket.

[Zancas]

I'd like to contribute to this issue, but there is no branch starting with "2027" in tahoe-lafs.git on github. I'm now confused about whether I should look in daira's github repo, or markberger's github repo... or what?

Where's the latest code?

[daira]

The latest code, rebased to master, is now at ​https://github.com/tahoe-lafs/tahoe-lafs/commits/2027-inconsistent-tahoe-cp-1.

However, this ticket is blocked on #2235 which changes how tahoe cp does Unicode coercion. Please don't commit it until that is fixed.

[daira]

See ​https://github.com/tahoe-lafs/tahoe-lafs/pull/138 (last two patches).

[daira]

Huh, those two commits are in a different order in the github pull request view than they are on the branch (​https://github.com/tahoe-lafs/tahoe-lafs/commits/2235-long-paths-on-windows-7).

On the pull request I see (topmost patch first):

Daira Hopwood   Adds test_ticket_2027 to test_cli.Cp. refs #2027 …                         d70d74a
Daira Hopwood   Fix and simplify argument handling for put/get (it was wrong for 'tah…     01d51f0
Daira Hopwood   Change other uses of os.path.expanduser and os.path.abspath. refs #2235 …  56bdb1f
Daira Hopwood   Changes filename to unicode before placing the file. refs #2027 …          536fe30

but on the branch, [d70d74a] is the penultimate patch, just before [536fe30].

[daira]

Note that this could potentially interact with #2329.

[daira]

Replying to daira:

Huh, those two commits are in a different order in the github pull request view than they are on the branch...

​https://help.github.com/articles/why-are-my-commits-in-the-wrong-order/ suggests a possibility, but I didn't rebase that branch.

[daira]

Replying to daira:

Replying to daira:

Huh, those two commits are in a different order in the github pull request view than they are on the branch...

​https://help.github.com/articles/why-are-my-commits-in-the-wrong-order/ suggests a possibility, but I didn't rebase that branch.

Actually I think I did rebase it and just forgot.

[daira]

Fixed on the pr138 branch which was merged in [3afe827ad0cbdb41b2928d17c8bfbbaf5102acc8/trunk].

(Woohoo! This set of bugs has been irking me for some time.)