formatting
[Imported from Trac: page Capabilities, version 13]
parent
b5abc5c4d9
commit
4021a2daae
|
@ -21,15 +21,16 @@ but updated to take into account literal caps and immutable directories:
|
|||
12: mutable directory verify capability string URI:DIR2-Verifier:
|
||||
|
||||
13: unknown/future capability strings <anything else>
|
||||
```
|
||||
|
||||
In Tahoe-LAFS, mutable directories are built out of mutable files (a mutable directory is really
|
||||
just a particular way to interpret the contents of a given mutable file), and
|
||||
non-directory mutable files aren't used very much. All normal data files are
|
||||
uploaded into immutable files by default.
|
||||
|
||||
Some capabilities can be used to derive others. If you have #1, you can
|
||||
derive #2 (but not the other way around). The full table is:
|
||||
|
||||
Some capabilities can be used to derive others. If you have !#1, you can
|
||||
derive !#2 (but not the other way around). The full table is:
|
||||
```
|
||||
write read verify
|
||||
--------------------
|
||||
#1 -> #2 }
|
||||
|
@ -39,27 +40,28 @@ derive #2 (but not the other way around). The full table is:
|
|||
#7 -> #8 }
|
||||
#9 } dircaps
|
||||
#10 -> #11 -> #12 }
|
||||
```
|
||||
|
||||
Deriving a weaker capability from a strong one is called "diminishing" the stronger one.
|
||||
|
||||
So we use "filecap" to talk about #1..6, but (since most files are immutable)
|
||||
we're usually talking about #1. We use "dircap" to talk about #7..12.
|
||||
We use "readcap" to talk about #{1,3,5,7,9,11}, but usually we refer to
|
||||
#{7,9,11} as a "directory readcap". We use "writecap" to talk about #4 and #10.
|
||||
So we use "filecap" to talk about !#1..6, but (since most files are immutable)
|
||||
we're usually talking about !#1. We use "dircap" to talk about !#7..12.
|
||||
We use "readcap" to talk about !#{1,3,5,7,9,11}, but usually we refer to
|
||||
!#{7,9,11} as a "directory readcap". We use "writecap" to talk about !#4 and !#10.
|
||||
|
||||
A "literal cap" or "LIT cap" stores the contents of a small file (#3) or
|
||||
directory (#9) in the capability itself.
|
||||
A "literal cap" or "LIT cap" stores the contents of a small file (!#3) or
|
||||
directory (!#9) in the capability itself.
|
||||
|
||||
A "verifycap" is the weakest capability that still allows every bit of every
|
||||
share to be validated (hashes checked, signatures verified, etc). That means
|
||||
#{2,6,8,12}.
|
||||
!#{2,6,8,12}.
|
||||
|
||||
When we talk about a "repaircap", we mean "the weakest capability that can
|
||||
still be used to repair the file". Given the current limitations of the
|
||||
repairer and our webapi, that means we're talking about #{1,4,7,10}.
|
||||
Eventually we'll fix this limitation, and any verifycap should be useable as
|
||||
a repaircap too. (There's much less work involved to let #2 repair a file or
|
||||
#8 repair a directory... it's just an incomplete API, rather than a fundamental
|
||||
repairer and our web-API, that means we're talking about !#{1,4,7,10}.
|
||||
Eventually we'll fix this limitation, and any verifycap should be usable as
|
||||
a repaircap too. (There's much less work involved to let !#2 repair a file or
|
||||
!#8 repair a directory... it's just an incomplete API, rather than a fundamental
|
||||
redesign of the server protocol.)
|
||||
|
||||
We then use the somewhat-vague term "rootcap" to refer to a cap (usually a
|
||||
|
@ -67,8 +69,6 @@ directory write cap) that is not present inside any directory, so the only
|
|||
way to ever reach it is to remember it somewhere outside of a Tahoe-LAFS
|
||||
filesystem. It might be remembered in the allmydata.com rootcap database
|
||||
(indexed by account name plus password), or it might be remembered in a
|
||||
~/.tahoe/private/aliases file, or it might just be written down on a piece
|
||||
`~/.tahoe/private/aliases` file, or it might just be written down on a piece
|
||||
of paper. The point is that you have to start from somewhere, and we refer
|
||||
to such a starting point as a "rootcap".
|
||||
|
||||
```
|
Loading…
Reference in a new issue