[tahoe-lafs-trac-stream] [tahoe-lafs] #1304: 'tahoe cp' copying to a mutable file should replace the contents

tahoe-lafs trac at tahoe-lafs.org
Fri Jul 29 10:10:00 PDT 2011


#1304: 'tahoe cp' copying to a mutable file should replace the contents
-----------------------------------+--------------------------------
     Reporter:  davidsarah         |      Owner:  kevan
         Type:  defect             |     Status:  new
     Priority:  major              |  Milestone:  1.9.0
    Component:  code-frontend-cli  |    Version:  1.8.1
   Resolution:                     |   Keywords:  tahoe-cp usability
Launchpad Bug:                     |
-----------------------------------+--------------------------------

Comment (by kevan):

 Thanks for the review, davidsarah. I've attached another patch with a new
 test.

 The error message that we test for is a webapi error message. That seems a
 bit lazy -- it didn't require any code changes, for example -- and it's
 not the most informative error message I've ever seen. The only way I've
 thought of to do better is to teach {{{tahoe cp}}} to inspect the error
 response from the webapi if it gets one so it can append an explanation to
 the output, and I'm not sure I like the idea of coupling {{{tahoe cp}}} to
 the exception messages printed by the webapi in that way.

 (another initially attractive option is a sanity check performed on
 {{{tahoe cp}}}'s targetmap before copying starts. Based on this, we could
 either abort the copy operation or print a warning if we found a readonly
 mutable target. All of that would rely upon JSON gathered from a different
 HTTP request than the request(s) actually modifying data, though, so any
 check would be inherently unreliable. Given that, I don't think I'd want
 to stop the copy operation if a readonly target was found, since I
 wouldn't want users to get the idea that we could do that reliably and I
 wouldn't want to annoy users if that fact got in their way, but I'm not as
 against printing a warning and then continuing, though at that point we
 might as well just figure out a way to write a better error message after
 the fact, since that solves the problem in more cases)

-- 
Ticket URL: <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1304#comment:10>
tahoe-lafs <http://tahoe-lafs.org>
secure decentralized storage


More information about the tahoe-lafs-trac-stream mailing list