[tahoe-lafs-trac-stream] [tahoe-lafs] #1643: presence of MDMF in aliases break the CLI < v1.9.0

tahoe-lafs trac at tahoe-lafs.org
Sun Dec 18 13:38:29 UTC 2011


#1643: presence of MDMF in aliases break the CLI < v1.9.0
-------------------------+-------------------------------------------------
     Reporter:  zooko    |      Owner:
         Type:  defect   |     Status:  new
     Priority:  major    |  Milestone:  undecided
    Component:  code-    |    Version:  1.9.0
  mutable                |   Keywords:  versioning forward-compatibility
   Resolution:           |  backward-compatibility mutable mdmf aliases
Launchpad Bug:           |
-------------------------+-------------------------------------------------

Comment (by zooko):

 Now what about backward-compatibility? Could we release a Tahoe-LAFS
 v1.9.1 so that if someone used Tahoe-LAFS v1.9.1 to create an MDMF alias
 and then switched back to using Tahoe-LAFS v1.6 ([wiki:OSPackages from
 Ubuntu Lucid]), their CLI would continue to work? (Not, of course, that it
 would be able to use one of the MDMF aliases if they specified an MDMF
 alias on the command-line -- only that it would continue to be able to use
 other non-MDMF aliases, as well as to do things that require no alias such
 as {{{tahoe mkdir}}}.)

 Hm... not really. I created those MDMF caps with {{{tahoe mkdir}}} or the
 WUI, and then I inserted them manually into {{{~/.tahoe/private/aliases}}}
 using vi. There's not much the software could do to help with this. When
 we do eventually switch {{{tahoe create-alias}}} over to creating MDMF in
 addition to SDMF directories [*], we ''could'' at that time make it put
 the resulting MDMF caps into {{{~/.tahoe/private/aliases-mdmf}}} instead
 of into {{{~/.tahoe/private/aliases}}}. That would protect a user of that
 future version of Tahoe-LAFS from making their {{{aliases}}} file
 poisonous to their old Tahoe-LAFS v1.6 installation when they run {{{tahoe
 create-alias}}}.

 [*] Aside: I really hope we eventually transition everything to all-MDMF-
 all-the-time and deprecate SDMF because two kinds of mutable things is a
 lot more complexity than one kind of mutable thing.

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


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