[tahoe-lafs-trac-stream] [tahoe-lafs] #1373: 'tahoe cp' should not make links to existing immutable files when the encoding parameters have changed

[tahoe-lafs]

#1373: 'tahoe cp' should not make links to existing immutable files when the
encoding parameters have changed
-----------------------------------+----------------------------------------
     Reporter:  davidsarah         |       Owner:                                                          
         Type:  defect             |      Status:  new                                                     
     Priority:  major              |   Milestone:  undecided                                               
    Component:  code-frontend-cli  |     Version:  1.8.2                                                   
   Resolution:                     |    Keywords:  tahoe-cp preservation availability rebalancing usability
Launchpad Bug:                     |  
-----------------------------------+----------------------------------------

Comment (by warner):

 I think 'tahoe cp' should not re-encode by default.. instead, I'd like to
 see an option like {{{--recode}}}, or maybe something that means "I really
 care about the current gateway's current encoding parameters, and I'm
 willing to lose convergence and spend bandwidth to make sure new files
 match those parameters", because I think most of the time people won't
 care enough to spend those things, and would prefer to have 'cp' continue
 to share existing immutable files.

 I agree that "tahoe cp -r" is a reasonable tool to do deep-modifications
 of files, things that will result in new filecaps.

 Also, if we're going to use a CLI command to do this, the brains of the
 operation should probably be in the gateway anyways: you wouldn't want the
 CLI tool to download the full contents of the file and then send them
 right back to the same gateway. Instead, you'd want a webapi command that
 takes an existing filecap and some new encoding parameters, and does the
 download/reencode/upload locally, then gives you back a new filecap. So
 it's not that the webapi needs to expose the encoding parameters, but it's
 more like it needs to expose a "copy iff encoding-parameters don't match
 my current defaults".

 That said, a good first step would probably be to make it possible for
 webapi clients to control the encoding parameters on a per-upload basis,
 probably by adding {{{?encoding=k,N}}} arguments to the PUT command. Then
 we can get some experience with how people want to use this sort of
 control, which I think should inform the creation of tools like deep-
 reencode.

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