[tahoe-dev] CLI mkdir inverse?

[Brian Warner]

On Mon, 4 May 2009 09:32:17 -0400
Ben Hyde <bhyde at pobox.com> wrote:

> That was my first guess; but then I created an alias - letting it do the
> mkdir for me - and I am unable to rm that alias.
> ...
> 
> Hm, now I'm thinking this is, in part, because I created the alias
> example via 'tahoe create-alias example'; i.e. let it do the mkdir.
> So there isn't anything to unlink it from.

Bingo. "rm" is used to remove a link: a link from some parent directory to
some child object (a file or a subdirectory). Your top-level alias isn't a
child of anything: the only place that remembers it is your aliases table (in
~/.tahoe/private/aliases). If you want to forget about it, just edit that
file and remove the line.

"tahoe mkdir" does two things: create a dircap for a new empty directory, and
possibly write that dircap into some existing parent directory associated
with a given child name. If you just do "tahoe mkdir" with no arguments, it
only does the first part, and returns the dircap. If you do "tahoe mkdir
alias:subdir" or "tahoe mkdir alias:intermediatedir/subdir", it will do both
parts (possibly multiple times, if it must create intermediate directories in
the process).

"tahoe create-alias ALIASNAME" does two things: create a dircap for a new
empty directory, and add that dircap into ~/.tahoe/private/aliases associated
with the given aliasname. This alises file is a local (real) file, not stored
in the tahoe grid, so "rm" doesn't know anything about it.

Remember that Tahoe doesn't have explicit/immediate garbage collection: "rm"
merely forgets about the reference, it doesn't instantly free up the space
for the objects that are no longer reachable. If you turn periodic GC on (see
docs/garbage-collection.txt for details), then the fact that those objects
are no longer reachable will eventually cause them to be collected, since
they wouldn't have their leases renewed.

cheers,
 -Brian