creation and management of "root" directories -- directories without parents

[zooko]

Tahoe v0.7.0 doesn't handle various cases where there are strange sets of servers, such as when you are on an airplane and there is only one server -- yourself. Tickets #232 -- "peer selection doesn't rebalance shares on overwrite of mutable file" and #213 -- "good handling of small numbers of servers, or strange choice of servers" are the tickets to fix these issues nicely. This ticket is the ticket to document this issue and set sane default settings so that users of v0.7.0 will be able to handle it.

[zooko]

See also #234 -- "Nice UI for creation of private directory".

[zooko]

Per ​this tahoe-dev thread, the new plan is to finish the "make a directory button" (#115), remove the automatically-make-a-private-directory feature, remove the start page, add doc about saving your directories and about making them accessible to the command-line tools.

[zooko]

As per ​this tahoe-dev message, we also need to:

• Document the fact that when you create a directory (or upload a file, or overwrite a mutable file), that the set of peers that your file will be stored on is probably "some of the peers that are currently connected" (up to 10 of them, usually).
• Remove the code that makes the automatic private directory (or "private vdrive"), makes the start.html page, and links to the start.html page from the front page.
• Replace it with documentation (possibly on-page?) that explain that if you want a private directory then you create one with the "create a directory" button and you don't share it with anyone else, and to explain that if you want to be able to get back to it later then you have to bookmark it or cut and paste it to some document.
• Document how to cut and paste it into ~/.tahoe/private/my_private_dir.cap, so that tahoe ls will subsequently work.
• Make it so that tahoe mkdir can create a directory even if one doesn't exist and print out the resulting directory read-write cap.
• Make it so that when reading out of ~/.tahoe/private/my_private_dir.cap, it tolerates $THECAP, as well as http://127.0.0.1:8123/uri/$THECAP, and tolerates the colons in the cap being URL-encoded.

We'll put some improvements off to v0.7.1, see #248 -- "better automation of management of the "root director(ies)".

[zooko]

Let's rename that file from ~/.tahoe/private/my_private_dir.cap to ~/.tahoe/private/root_dir.cap.

[warner]

so, calling it "root_dir.cap" implies that there's only one of them. One of the options we discussed was a file with one-line-per-root, or a directory with one-file-per-root, and allow multiple names (perhaps one that is private, and another that is public, or shared between a group of users).

Had we come to a conclusion on this one yet?

[zooko]

I believe the conclusion we came to is to put off answering those questions to > v0.7.0, i.e. #248 -- "better automation of management of the "root director(ies)".

In v0.7.0 there is effectively only one of them, so let's call it root_dir.cap. Okay?

[warner]

eh, ok, good enough. I'm not excited about the idea of changing this in 0.7.0 and then changing it again right away in 0.7.1, but neither am I excited about the idea of fighting it. Go for it.

[zooko]

The ones that I just did (in 65a8a8c405b97cbc, 6a2e5d4aeaa9c261, acfb11d26f66d68b, 23961448dab2af95, ab4303609daf16f8, and 32d2cc8abaa15e5e), are hereby struck-through:

• Document the fact that when you create a directory (or upload a file, or overwrite a mutable file), that the set of peers that your file will be stored on is probably "some of the peers that are currently connected" (up to 10 of them, usually).
• Remove the code that makes the automatic private directory (or "private vdrive"), makes the start.html page, and links to the start.html page from the front page.
• Replace it with documentation (possibly on-page?) that explain that if you want a private directory then you create one with the "create a directory" button and you don't share it with anyone else, and to explain that if you want to be able to get back to it later then you have to bookmark it or cut and paste it to some document.
• Document how to cut and paste it into ~/.tahoe/private/my_private_dir.cap, so that tahoe ls will subsequently work.
• Make it so that tahoe mkdir can create a directory even if one doesn't exist and print out the resulting directory read-write cap.
• Make it so that when reading out of ~/.tahoe/private/my_private_dir.cap, it tolerates $THECAP, as well as ​http://127.0.0.1:8123/uri/$THECAP, and tolerates the colons in the cap being URL-encoded.

I've started on that last one: implementing "tahoe mkdir", which can be used to create a new empty directory linked into an existing directory or not so linked.

[zooko]

I moved "create tahoe mkdir" to a new ticket for Milestone v0.7.1: #259

[zooko]

Okay, I'm going to "not bother" on these two pieces, because I don't see a good place for these docs, and I think the best way to explain this is to explain the underlying mechanism so that it is "obvious" to the user that they should use the mechanism in this way.

Closing this ticket as fixed. :-)

• Document the fact that when you create a directory (or upload a file, or overwrite a mutable file), that the set of peers that your file will be stored on is probably "some of the peers that are currently connected" (up to 10 of them, usually).
• Replace it with documentation (possibly on-page?) that explain that if you want a private directory then you create one with the "create a directory" button and you don't share it with anyone else, and to explain that if you want to be able to get back to it later then you have to bookmark it or cut and paste it to some document.