[tahoe-dev] immutable directories!

[Brian Warner]

Zooko Wilcox-O'Hearn wrote:
> On Thursday, 2009-11-19, at 21:26 , Brian Warner wrote:
> 
>> I can't think of other obvious ways to create immutable directories.
>> Can you imagine any sort of WUI button for this? We don't have a "cp"
>> or "cp -r" button, and it isn't clear that you could provide one in a
>> one-directory-view-at-a-time WUI interface anyways. So I'm ok with
>> sticking to the CLI commands for now.
> 
> What about a button that makes a deep-immutable copy of the directory
> that you're currently looking at?

Hm.. would the new directory be attached anywhere? It can't be attached
to the parent of the dirnode you're currently looking at (since you
don't have its cap from there), so I can only think of a couple of
options. Assuming that you're looking at directory A and that it
contains (among other things) a subdirectory B:

 * in the "more info" or "dirnode forms" section, have a button labeled
   "create unlinked deep-immutable copy of this directory". When you
   push it, after a (potentially long) pause, you wind up at a new
   directory view, unlinked from anywhere, with IMM(A). Maybe with an
   extra message at the top that says "make sure you bookmark this!".

 * on the A view, in the row for B, next to the "Delete" and "Rename"
   buttons, we add a "create deep-immutable copy of this directory"
   button. When you push it, after a pause, you wind up back at the A
   view, but now there's a new row named "(immutable copy of) B". Once
   copied, you could rename it to something else.

The first button seems less-than-ideally-usable, since you have to
immediately bookmark the new dircap (or lose it). It might be the case
that you're freezing this directory so you can hand it to someone else,
and never want to touch it again, so the ephemeral nature of the newly
created DIR-IMM isn't such an issue. But my guess is that people will be
pushing that button and accidentally discarding the results a lot.

The second button seems marginally more useful, but hard to explain,
especially in the limited space the WUI view can offer (it has to go on
the child's row, not on the more-info page, since it affects the parent
directory, as do "delete" and "rename"). If we added this, I could
imagine wanting to add a few extra directory-copying buttons (normal "cp
-r", and a form that creates a mutable copy of immutable directories),
which would be pretty crowded. Also, long-running deep-traversal
operations like this should probably be a bit more guarded or at least
obviously expensive-looking, like the warnings we have on the deep-check
and manifest buttons.

Maybe a "Copy.." hyperlink on each child row, which goes to a page whose
URL includes both the parentdircap and the childname, and has a list of
buttons for the various types of copies. That would give us room for a
target childname too (which would be pre-filled with "Copy of B", but
editable), and some places to explain what the different options are.
For files, you might be mutablizing an immutable file, immutablizing a
mutable file, making a new mutable file with the same contents as the
original mutable file, or making a new link to an existing immutable
file. For deep-copy of a directory, you might be creating only immutable
directories (and immutablizing all files), creating the same dirnode
types as the original (but duplicating any mutable files/dirs), creating
only mutable directories (but using the same filenode type as the
original, duplicating any mutable files), or [maximal work] creating
only mutable files/dirs (making a brand new mutable object for
absolutely everything).


So, has anybody found themselves wanting a WUI button like this? I
haven't personally found a need for "copy" very often. When I copy
things on other filesystems, the target is almost always in a different
directory. So I hesitate to put a lot of effort into a WUI "copy" button
that's limited to creating things in the same directory as the source
(especially when we're lacking a "move" button that can cross
directories). I think it'd be more useful in something more powerful
than the WUI, maybe a javascript frontend that can show you multiple
folders at the same time, with drag-and-drop between them, or something.
A SuperWUI, if you will.

>> Error during GET: 400 Bad Request GET unknown: can only do t=info, not t=json

> Yes, I think that error message would confuse users as it is.

Ok, I've opened #837 to improve that one.

cheers,
 -Brian