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

[tahoe-lafs]

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

Comment (by kevan):

 In the weekly phonecall of two weeks ago (I think), I mentioned that I
 thought this was a bug in the webapi. That is wrong -- I misunderstood how
 {{{tahoe cp}}} assigns sources to targets.

 I think that the fact that {{{tahoe cp}}} will replace a mutable file with
 an immutable file is pretty unintuitive, and that's what it does now.
 Replacing the old contents with new contents also helps {{{tahoe cp}}}
 preserve use cases that rely on mutable files in directories having
 consistent caps after updates.

 How do we want to behave when {{{tahoe cp}}}'s authority is inadequate to
 replace the contents of the target? I like failure in that case; I don't
 like the idea of falling back to directory modification from content
 replacement for mutable files, since they're pretty different behaviors.

 I've attached a patch. I'll set 'review-needed' once we've decided what to
 do when the target mutable file isn't writable and I've written a test for
 that.

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