[tahoe-dev] Deleting a zero-length filename?

[Brian Warner]

Kyle Markley wrote:

> I've been spending a lot of time looking through the tahoe educational
> materials and tinkering with it to get my backups working smoothly,
> and I'd like to voice how pleased I am. Tahoe is a very clever thing.

Thanks!

> Of course, I would be happier if the documentation were more complete
> and the error handling were more obvious and more user friendly, but I
> know I'm a hard guy to please in those respects. :)

Yeah, docs are always a weak point. If you're in a position to write up
a few questions that you wondered about (with or without answers),
could you add a ticket or even just post an email with them? One thing
that we're lacking is good awareness of what needs to be explained. Once
you get too familiar with the architecture and the code, it gets hard to
realize how you got to that point, which is exactly the sort of thing
that needs to be written down :).

I'm starting to think that a switch to replace every single webapi
exception with a plain-text exception (instead of the HTMLized
traceback, with locals and color-coded styles and whatnot) would be a
good idea. I see exceptions far more frequently from the CLI tools than
from a web browser, and readable-but-less-information would be
preferable to sometimes-more-information-but-sometimes-unreadable.

> Currently, I'm puzzled a bit by the 'check' operation. It was my
> understanding that to do a check, I need only the verify cap. But when
> I try to check my root directory on the production grid, it only
> succeeds if I use the write or read cap.

You're right, it's a bug (or at least an unimplemented feature).
Fundamentally, a immutable 'check' operation merely needs the storage
index (which is the left half of the verifycap), and a 'verify'
operation merely needs the verifycap. There's internal code to perform
check/verify/repair from a verifycap, but we haven't yet written the
code to provide the webapi pathway to exercise it (tickets #482, #847).

For mutable files, check/verify should also be performable from
storage-index/verifycap, but we don't even have the internal APIs for it
yet (ticket #746). And there are fundamental problems with doing repair
from anything weaker than a writecap (#625)


> And, does anyone know why I've never been able to connect to the
> production grid helper?

My guess is that the prodgrid helper is down. I saw mail from zooko
suggesting that those machines aren't feeling very well right now.


cheers,
 -Brian