[tahoe-dev] [tahoe-lafs] #658: "tahoe cp" should use backupdb, in both directions

[tahoe-lafs]

#658: "tahoe cp" should use backupdb, in both directions
-------------------------------------------+--------------------------------
 Reporter:  warner                         |           Owner:           
     Type:  enhancement                    |          Status:  new      
 Priority:  major                          |       Milestone:  undecided
Component:  code-frontend-cli              |         Version:  1.3.0    
 Keywords:  backupdb cp usability newcaps  |   Launchpad_bug:           
-------------------------------------------+--------------------------------
Changes (by davidsarah):

  * keywords:  backupdb cp usability => backupdb cp usability newcaps


Comment:

 Plaintext hashes would be a more robust way of doing this than
 URI+timestamp (but dependent on #453).

 IOW, for downloading a file:
 * if the source cap is to an immutable file, the read cap might be
 sufficient to verify that the existing copy has the same plaintext hash.
 * if the source cap is to a mutable file, {{{cp}}} would need to go to the
 servers to find the concensus value for the plaintext hash of the current
 version. Then it would proceed as for an immutable file.

 If the existing file is the correct one, it should still be {{{touch}}}ed
 to update its mtime.

 For uploading a file, if there is an existing copy then you would have to
 verify it.

 The storage server protocol and webapi would need to be able to return a
 hash of the file first. (See
 http://www.usenix.org/events/nsdi04/tech/full_papers/mogul/mogul.pdf for a
 similar protocol with some relevant discussion of design issues.)

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