#2027 closed defect (fixed)

Inconsistent 'tahoe cp' behavior

Reported by: markberger Owned by:
Priority: normal Milestone: 1.10.1
Component: code-frontend-cli Version: 1.10.0
Keywords: usability error cli tahoe-cp review-needed Cc:
Launchpad Bug:

Description (last modified by daira)

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.

Change History (19)

comment:1 Changed at 2013-07-17T16:15:15Z by daira

  • Description modified (diff)
  • Keywords usability error cli tahoe-cp easy added
  • Owner set to daira
  • Status changed from new to assigned

comment:2 Changed at 2013-07-17T16:16:54Z by daira

  • Description modified (diff)

All four cases in the description should succeed.

comment:3 Changed at 2013-07-17T16:20:20Z by daira

  • Description modified (diff)

comment:4 Changed at 2013-07-17T16:22:30Z by daira

  • Description modified (diff)
  • Summary changed from Inconsistent 'tahoe cp' Behavior to Inconsistent 'tahoe cp' behavior

comment:5 Changed at 2013-07-26T15:36:51Z by markberger

  • Owner changed from daira to markberger
  • Status changed from assigned to new

comment:6 Changed at 2013-07-26T16:44:19Z by markberger

  • Keywords review-needed added

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

comment:7 Changed at 2013-08-02T02:10:53Z by daira

  • Keywords review-needed removed

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).

comment:8 Changed at 2013-08-02T04:31:01Z by daira

  • Owner changed from markberger to daira
  • Status changed from new to assigned

Reviewing.

comment:9 Changed at 2014-09-13T09:40:43Z by daira

  • Milestone changed from soon to 1.11.0

comment:10 Changed at 2014-09-13T09:43:15Z by daira

#2029 was merged into this ticket.

comment:11 Changed at 2014-10-10T18:15:54Z by 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?

comment:12 Changed at 2014-10-11T22:49:40Z by 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 #2259 which changes how tahoe cp does Unicode coercion. Please don't commit it until that is fixed.

Version 0, edited at 2014-10-11T22:49:40Z by daira (next)

comment:13 Changed at 2014-10-11T23:20:32Z by daira

  • Keywords easy removed

comment:14 Changed at 2015-01-29T19:34:01Z by daira

  • Keywords review-needed added
  • Owner daira deleted
  • Status changed from assigned to new

comment:15 follow-up: Changed at 2015-01-29T19:40:56Z by 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].

comment:16 Changed at 2015-01-29T19:42:51Z by daira

Note that this could potentially interact with #2329.

comment:17 in reply to: ↑ 15 ; follow-up: Changed at 2015-01-29T21:18:09Z by 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.

comment:18 in reply to: ↑ 17 Changed at 2015-01-29T23:55:49Z by 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.

comment:19 Changed at 2015-02-05T02:10:04Z by daira

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

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

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

Note: See TracTickets for help on using tickets.