[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 davidsarah):

 Replying to [comment:2 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 disagree, because I don't think that changes in the encoding parameters
 will be common enough for the bandwidth and space usage to be a
 significant issue. The user wouldn't have changed the parameters if they
 didn't want new files to have the new parameters. A copy of a file made by
 {{{tahoe cp}}} is logically a new file.

 > 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.

 It wouldn't do that. It would compare the parameters in the URI that it is
 copying with the current parameters. There's no need for any web-API
 request to compare parameters per-file, because the URI has already been
 obtained from a download of the parent directory (or from the command-
 line).

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