read-only access to a parent directory, then Bob will get read-only access
(and *not* read-write access) to its children.
-Relative to the previous "vdrive-server" based scheme, the current
+Relative to the previous "vdrive server"-based scheme, the current
distributed dirnode approach gives better availability, but cannot guarantee
updateness quite as well, and requires far more network traffic for each
retrieval and update. Mutable files are somewhat less available than
repairer does not get to read the files or directories that it is helping to
keep alive.
-After each change to the user's vdrive, the client creates a manifest and
+After each change to the user's file store, the client creates a manifest and
looks for differences from their previous version. Anything which was removed
prompts the client to send out lease-cancellation messages, allowing the data
to be deleted.
.. _`Prime Coordination Directive`: ../write_coordination.rst
A suitable UI needs to be created to allow users to easily perform this
-sharing action: dragging a folder their vdrive to an IM or email user icon,
-for example. The UI will need to give the sending user an opportunity to
-indicate whether they want to grant read-write or read-only access to the
-recipient. The recipient then needs an interface to drag the new folder into
-their file store and give it a home.
+sharing action: dragging a folder from their file store to an IM or email
+user icon, for example. The UI will need to give the sending user an
+opportunity to indicate whether they want to grant read-write or read-only
+access to the recipient. The recipient then needs an interface to drag the
+new folder into their file store and give it a home.
Revocation
==========
File URIs
=========
-The lowest layer of the Tahoe architecture (the "grid") is reponsible for
-mapping URIs to data. This is basically a distributed hash table, in which
-the URI is the key, and some sequence of bytes is the value.
+The lowest layer of the Tahoe architecture (the "key-value store") is
+reponsible for mapping URIs to data. This is basically a distributed
+hash table, in which the URI is the key, and some sequence of bytes is
+the value.
There are two kinds of entries in this table: immutable and mutable. For
immutable entries, the URI represents a fixed chunk of data. The URI itself
For mutable entries, the URI identifies a "slot" or "container", which can be
filled with different pieces of data at different times.
-It is important to note that the "files" described by these URIs are just a
-bunch of bytes, and that **no** filenames or other metadata is retained at
-this layer. The vdrive layer (which sits above the grid layer) is entirely
-responsible for directories and filenames and the like.
+It is important to note that the values referenced by these URIs are just
+sequences of bytes, and that **no** filenames or other metadata is retained at
+this layer. The file store layer (which sits above the key-value store layer)
+is entirely responsible for directories and filenames and the like.
CHK URIs
--------
Directory URIs
==============
-The grid layer provides a mapping from URI to data. To turn this into a graph
-of directories and files, the "vdrive" layer (which sits on top of the grid
-layer) needs to keep track of "directory nodes", or "dirnodes" for short.
-dirnodes.rst_ describes how these work.
+The key-value store layer provides a mapping from URI to data. To turn this
+into a graph of directories and files, the "file store" layer (which sits on
+top of the key-value store layer) needs to keep track of "directory nodes",
+or "dirnodes" for short. dirnodes.rst_ describes how these work.
Dirnodes are contained inside mutable files, and are thus simply a particular
way to interpret the contents of these files. As a result, a directory
projects / tahoe-lafs / tahoe-lafs.git / commitdiff