specifying a format= argument in the query string. format=MDMF creates an
MDMF mutable file. format=SDMF creates an SDMF mutable file. format=CHK
creates an immutable file. The value of the format argument is
- case-insensitive. If no format is specified, the newly-created file will be
- immutable (but see below).
-
- For compatibility with previous versions of Tahoe-LAFS, the web-API will
- also accept a mutable=true argument in the query string. If mutable=true is
- given, then the new file will be mutable, and its format will be the default
- mutable file format, as configured by the [client]mutable.format option of
- tahoe.cfg on the Tahoe-LAFS node hosting the webapi server. Use of
- mutable=true is discouraged; new code should use format= instead of
- mutable=true (unless it needs to be compatible with web-API servers older
- than v1.9.0). If neither format= nor mutable=true are given, the
- newly-created file will be immutable.
-
- This returns the file-cap of the resulting file. If a new file was created
- by this method, the HTTP response code (as dictated by rfc2616) will be set
- to 201 CREATED. If an existing file was replaced or modified, the response
- code will be 200 OK.
+ case-insensitive.
+
+ The web-API also accepts a mutable=true argument in the query string.
+ If mutable=true is given, then the new file will be mutable, and its
+ format will be the default mutable file format, as configured by the
+ [client]mutable.format option of tahoe.cfg on the Tahoe-LAFS node hosting
+ the webapi server.
+
+ If neither format= nor mutable=true are given, the newly-created file
+ will be immutable.
+
+ This method returns the file-cap of the resulting file. If a new file
+ was created, the HTTP response code (as dictated by `RFC2616`_) will be
+ set to 201 CREATED. If an existing file was replaced or modified, the
+ response code will be 200 OK.
Note that the 'curl -T localfile http://127.0.0.1:3456/uri/$DIRCAP/foo.txt'
command can be used to invoke this operation.
+.. _RFC2616: https://tools.ietf.org/html/rfc2616
+
``PUT /uri``
This uploads a file, and produces a file-cap for the contents, but does not
gap between the two implementations (my original intention had been to make
SDMF a clean subset of MDMF, where any single-segment MDMF file could be
handled by the old SDMF code). In the fall of 2011, Kevan's code was finally
-integrated, and first made available in the Tahoe-1.9.0 release.
+integrated, and first made available in the Tahoe-LAFS v1.9.0 release.
+
SDMF vs. MDMF
-------------
than from an SDMF file, although the overall download will then proceed at
the same rate.
-We've decided to make it opt-in for now: mutable files default to
-SDMF format unless explicitly configured to use MDMF, either in ``tahoe.cfg``
+Starting from Tahoe-LAFS v1.11.0, mutable files default to MDMF format
+unless explicitly configured to use SDMF, either in ``tahoe.cfg``
(see `<configuration.rst>`__) or in the WUI or CLI command that created a
-new mutable file.
+new mutable file. In previous releases, the default was SDMF.
The code can read and modify existing files of either format without user
-intervention. We expect to make MDMF the default in a subsequent release,
-perhaps 2.0.
+intervention.
Which format should you use? SDMF works well for files up to a few MB, and
-can be handled by older versions (Tahoe-1.8.3 and earlier). If you do not
-need to support older clients, want to efficiently work with mutable files,
-and have code which will use Range: headers that make partial reads and
-writes, then MDMF is for you.
+can be handled by older versions (Tahoe-LAFS v1.8.3 and earlier). If you do
+not need to support older clients, want to efficiently work with mutable
+files, and have code which will use Range: headers that make partial reads
+and writes, then MDMF is for you.
Consistency vs. Availability
limited to confirming that the data retrieved matches *some* data that was
uploaded in the past, but not _which_ version of that data.
-The format of the write-cap for mutable files is::
+The format of the write-cap for mutable files, for SDMF and MDMF files
+respectively, is::
URI:SSK:(writekey):(fingerprint)
+ URI:MDMF:(writekey):(fingerprint)
Where (writekey) is the base32 encoding of the 16-byte AES encryption key
that is used to encrypt the RSA private key, and (fingerprint) is the base32
encoded 32-byte SHA-256 hash of the RSA public key. For more details about
the way these keys are used, please see mutable.rst_.
-The format for mutable read-caps is::
+The format for mutable read-caps, for SDMF and MDMF files respectively, is::
URI:SSK-RO:(readkey):(fingerprint)
+ URI:MDMF-RO:(readkey):(fingerprint)
The read-cap is just like the write-cap except it contains the other AES
encryption key: the one used for encrypting the mutable file's contents. This
write-cap looks a lot like a mutable-file write-cap::
URI:DIR2:(writekey):(fingerprint)
+ URI:DIR2-MDMF:(writekey):(fingerprint)
Likewise directory read-caps (which provide read-only access to the
directory) look much like mutable-file read-caps::
URI:DIR2-RO:(readkey):(fingerprint)
+ URI:DIR2-MDMF-RO:(readkey):(fingerprint)
Historical note: the "DIR2" prefix is used because the non-distributed
dirnodes in earlier Tahoe releases had already claimed the "DIR" prefix.