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

New Issue

zooko · 2007-12-18T00:58:25Z

zooko commented

2007-12-18 00:58:25 +00:00

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 added the

labels 2007-12-18 00:58:25 +00:00

zooko added this to the 0.7.0 milestone 2007-12-18 00:58:25 +00:00

zooko self-assigned this 2007-12-18 00:58:25 +00:00

zooko commented

2007-12-19 22:48:49 +00:00

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

zooko commented

2007-12-22 21:24:38 +00:00

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.

Per [this tahoe-dev thread](http://allmydata.org/pipermail/tahoe-dev/2007-December/000280.html), 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 commented

2007-12-25 22:43:29 +00:00

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

As per [this tahoe-dev message](http://allmydata.org/pipermail/tahoe-dev/2007-December/000282.html), 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 changed title from ~~work-around the poor handling of weird server sets in v0.7.0~~ to creation and management of "rootdirectories without parents

2007-12-25 22:43:29 +00:00

zooko changed title from ~~creation and management of "rootdirectories without parents~~ to creation and management of "root" directories -- directories without parents

2007-12-25 22:43:40 +00:00

zooko commented

2007-12-25 23:04:57 +00:00

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

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

warner commented

2007-12-26 07:42:15 +00:00

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?

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 commented

2007-12-28 00:47:03 +00:00

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?

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 commented

2007-12-31 21:39:02 +00:00

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 commented

2008-01-04 00:15:19 +00:00

The ones that I just did (in changeset:65a8a8c405b97cbc, changeset:6a2e5d4aeaa9c261, changeset:acfb11d26f66d68b, changeset:23961448dab2af95, changeset:ab4303609daf16f8, and changeset: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.

The ones that I just did (in changeset:65a8a8c405b97cbc, changeset:6a2e5d4aeaa9c261, changeset:acfb11d26f66d68b, changeset:23961448dab2af95, changeset:ab4303609daf16f8, and changeset: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 commented

2008-01-05 20:26:01 +00:00

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

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

zooko commented

2008-01-05 20:27:37 +00:00

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.

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.

zooko added the

fixed

label 2008-01-05 20:27:37 +00:00

zooko closed this issue

2008-01-05 20:27:37 +00:00

Sign in to join this conversation.