[tahoe-dev] [tahoe-lafs] #761: "tahoe cp $DIRCAP/$PATH $LOCAL" raises AttributeError

[tahoe-lafs]

#761: "tahoe cp $DIRCAP/$PATH $LOCAL" raises AttributeError
-------------------------------+--------------------------------------------
 Reporter:  zooko              |           Owner:  warner    
     Type:  defect             |          Status:  assigned  
 Priority:  major              |       Milestone:  eventually
Component:  code-frontend-cli  |         Version:  1.4.1     
 Keywords:  review             |   Launchpad_bug:            
-------------------------------+--------------------------------------------

Comment(by warner):

 One comment about the original issue that zooko described: the help text
 suggested running "{{{cp DIRCAP/filename ./}}}" (note that the target is
 "./"), but the failing example actually ran
 "{{{cp -r DIRCAP/filename filename2}}}" (note the -r and "filename2"
 target). The command in the help text works correctly.

 Kevan: thanks for the comprehensive testing! If I might compress the cases
 down to a brief list, I think it looks like this:

  * cp -r DIRCAP/filename1 filename2 : EXCEPTION (zooko's example)
  * cp FILECAP dirname : EXCEPTION
  * cp DIRCAP/filename dirname : EXCEPTION
  * cp FILECAP filename : OK
  * cp DIRCAP/filename filename : OK
  * cp FILECAP filename : OK (overwrite)
  * cp DIRCAP/filename filename : OK (overwrite)
  * cp -r FILECAP dirname : OK
  * cp -r DIRCAP dirname : OK

 The behavior of plain old /bin/cp, with or without -r, is pretty ugly, and
 there are a lot of variables: source has-or-does-not-have trailing slash,
 dest trailing slash, dest not-exists/is-file/is-dir, -r-or-not. Other
 programs that try to look kind of like /bin/cp (like rsync and scp) have
 slightly different semantics.

 I like your conclusions, that the first case ("cp FILECAP dirname") should
 complain cleanly, and the second case ("cp DIRCAP/filename dirname")
 should
 result in dirname/filename being created.

 I don't know what "cp -r FILECAP dirname" should do (it seems plausible
 that
 -r should assert that the source argument is a directory), but I think the
 current behavior is acceptable. Given that, it seems like zooko's "cp -r
 DIRCAP/filename1 filename2" ought to behave just like the non-recursive
 "cp
 DIRCAP/filename1 filename2".

 Anyways, those are my feelings. I'll go review your patch now.

-- 
Ticket URL: <http://allmydata.org/trac/tahoe/ticket/761#comment:5>
tahoe-lafs <http://allmydata.org>
secure decentralized file storage grid