1. `Reading a file`_
2. `Writing/Uploading a File`_
3. `Creating a New Directory`_
- 4. `Getting Information About A File Or Directory (as JSON)`_
+ 4. `Getting Information About a File Or Directory (as JSON)`_
5. `Attaching an Existing File or Directory by its read- or write-cap`_
6. `Adding Multiple Files or Directories to a Parent Directory at Once`_
7. `Unlinking a File or Directory`_
6. `Browser Operations: Human-Oriented Interfaces`_
- 1. `Viewing A Directory (as HTML)`_
+ 1. `Viewing a Directory (as HTML)`_
2. `Viewing/Downloading a File`_
- 3. `Getting Information About A File Or Directory (as HTML)`_
+ 3. `Getting Information About a File Or Directory (as HTML)`_
4. `Creating a Directory`_
5. `Uploading a File`_
- 6. `Attaching An Existing File Or Directory (by URI)`_
- 7. `Unlinking A Child`_
- 8. `Renaming A Child`_
- 9. `Other Utilities`_
- 10. `Debugging and Testing Features`_
+ 6. `Attaching an Existing File Or Directory (by URI)`_
+ 7. `Unlinking a Child`_
+ 8. `Renaming a Child`_
+ 9. `Relinking ("Moving") a Child`_
+ 10. `Other Utilities`_
+ 11. `Debugging and Testing Features`_
7. `Other Useful Pages`_
8. `Static Files in /public_html`_
http://127.0.0.1:3456/uri/ + $CAP
-So, to access the directory named above (which happens to be the
-publically-writeable sample directory on the Tahoe test grid, described at
-http://allmydata.org/trac/tahoe-lafs/wiki/TestGrid), the URL would be::
+So, to access the directory named above, the URL would be::
http://127.0.0.1:3456/uri/URI%3ADIR2%3Adjrdkfawoqihigoett4g6auz6a%3Ajx5mplfpwexnoqff7y5e4zjus4lidm76dcuarpct7cckorh2dpgq/
/uri/$DIRCAP/
/uri/$FILECAP
+/cap can be used as a synonym for /uri. If interoperability with older web-API
+servers is required, /uri should be used.
Child Lookup
------------
operations that are intended for web browsers.
-Reading A File
+Reading a File
--------------
``GET /uri/$FILECAP``
purpose.
-Writing/Uploading A File
+Writing/Uploading a File
------------------------
``PUT /uri/$FILECAP``
interprets those arguments in the same way as the linked forms of PUT
described immediately above.
-Creating A New Directory
+Creating a New Directory
------------------------
``POST /uri?t=mkdir``
{
"Fran\u00e7ais": [ "filenode", {
"ro_uri": "URI:CHK:...",
- "size": bytes,
"metadata": {
"ctime": 1202777696.7564139,
"mtime": 1202777696.7564139,
or already has a child named NAME.
-Getting Information About A File Or Directory (as JSON)
+Getting Information About a File Or Directory (as JSON)
-------------------------------------------------------
``GET /uri/$FILECAP?t=json``
existing "tahoe" metadata is preserved. The metadata["tahoe"] value is
reserved for metadata generated by the tahoe node itself. The only two keys
currently placed here are "linkcrtime" and "linkmotime". For details, see
- the section above entitled "Get Information About A File Or Directory (as
+ the section above entitled "Getting Information About a File Or Directory (as
JSON)", in the "About the metadata" subsection.
Note that this command was introduced with the name "set_children", which
descriptions below display the most significant arguments as URL query args.
-Viewing A Directory (as HTML)
+Viewing a Directory (as HTML)
-----------------------------
``GET /uri/$DIRCAP/[SUBDIRS../]``
this form can *only* be used with file caps; it is an error to use a
directory cap after the /named/ prefix.
+ URLs may also use /file/$FILECAP/FILENAME as a synonym for
+ /named/$FILECAP/FILENAME.
-Getting Information About A File Or Directory (as HTML)
+Getting Information About a File Or Directory (as HTML)
-------------------------------------------------------
``GET /uri/$FILECAP?t=info``
This accepts a format= argument in the query string. Refer to the
documentation of POST /uri/$DIRCAP/[SUBDIRS../]?t=mkdir&name=CHILDNAME in
- `Creating A New Directory`_ for information on the behavior of the format=
+ `Creating a New Directory`_ for information on the behavior of the format=
argument.
If a "when_done=URL" argument is provided, the HTTP response will cause the
operation took, etc.
This accepts format= and mutable=true query string arguments. Refer to
- `Writing/Uploading A File`_ for information on the behavior of format= and
+ `Writing/Uploading a File`_ for information on the behavior of format= and
mutable=true.
``POST /uri/$DIRCAP/[SUBDIRS../]?t=upload``
already exist.
This accepts format= and mutable=true query string arguments. Refer to
- `Writing/Uploading A File`_ for information on the behavior of format= and
+ `Writing/Uploading a File`_ for information on the behavior of format= and
mutable=true.
If a "when_done=URL" argument is provided, the HTTP response will cause the
This accepts the same replace= argument as POST t=upload.
-Unlinking A Child
+Unlinking a Child
-----------------
``POST /uri/$DIRCAP/[SUBDIRS../]?t=delete&name=CHILDNAME``
-``POST /uri/$DIRCAP/[SUBDIRS../]?t=unlink&name=CHILDNAME``
+``POST /uri/$DIRCAP/[SUBDIRS../]?t=unlink&name=CHILDNAME`` (Tahoe >= v1.9)
This instructs the node to remove a child object (file or subdirectory) from
the given directory, which must be mutable. Note that the entire subtree is
be used.
-Renaming A Child
+Renaming a Child
----------------
``POST /uri/$DIRCAP/[SUBDIRS../]?t=rename&from_name=OLD&to_name=NEW``
same child-cap under the new name, except that it preserves metadata. This
operation cannot move the child to a different directory.
- This operation will replace any existing child of the new name, making it
- behave like the UNIX "``mv -f``" command.
+ The default behavior is to overwrite any existing link at the destination
+ (replace=true). To prevent this (and make the operation return an error
+ instead of overwriting), add a "replace=false" argument. With replace=false,
+ this operation will return an HTTP 409 "Conflict" error if the destination
+ is not the same link as the source and there is already a link at the
+ destination, rather than overwriting the existing link. To allow the
+ operation to overwrite a link to a file, but return an HTTP 409 error when
+ trying to overwrite a link to a directory, use "replace=only-files" (this
+ behavior is closer to the traditional UNIX "mv" command). Note that "true",
+ "t", and "1" are all synonyms for "True"; "false", "f", and "0" are synonyms
+ for "False"; and the parameter is case-insensitive.
+
+
+Relinking ("Moving") a Child
+----------------------------
+
+``POST /uri/$DIRCAP/[SUBDIRS../]?t=relink&from_name=OLD&to_dir=$NEWDIRCAP/[NEWSUBDIRS../]&to_name=NEW``
+ ``[&replace=true|false|only-files]`` (Tahoe >= v1.10)
+
+ This instructs the node to move a child of the given source directory, into
+ a different directory and/or to a different name. The command is named
+ ``relink`` because what it does is add a new link to the child from the new
+ location, then remove the old link. Nothing is actually "moved": the child
+ is still reachable through any path from which it was formerly reachable,
+ and the storage space occupied by its ciphertext is not affected.
+
+ The source and destination directories must be writeable. If {{{to_dir}}} is
+ not present, the child link is renamed within the same directory. If
+ {{{to_name}}} is not present then it defaults to {{{from_name}}}. If the
+ destination link (directory and name) is the same as the source link, the
+ operation has no effect.
+
+ Metadata from the source directory entry is preserved. Multiple levels of
+ descent in the source and destination paths are supported.
+
+ This operation will return an HTTP 404 "Not Found" error if
+ ``$DIRCAP/[SUBDIRS../]``, the child being moved, or the destination
+ directory does not exist. It will return an HTTP 400 "Bad Request" error
+ if any entry in the source or destination paths is not a directory.
+
+ The default behavior is to overwrite any existing link at the destination
+ (replace=true). To prevent this (and make the operation return an error
+ instead of overwriting), add a "replace=false" argument. With replace=false,
+ this operation will return an HTTP 409 "Conflict" error if the destination
+ is not the same link as the source and there is already a link at the
+ destination, rather than overwriting the existing link. To allow the
+ operation to overwrite a link to a file, but return an HTTP 409 error when
+ trying to overwrite a link to a directory, use "replace=only-files" (this
+ behavior is closer to the traditional UNIX "mv" command). Note that "true",
+ "t", and "1" are all synonyms for "True"; "false", "f", and "0" are synonyms
+ for "False"; and the parameter is case-insensitive.
+
+ When relinking into a different directory, for safety, the child link is
+ not removed from the old directory until it has been successfully added to
+ the new directory. This implies that in case of a crash or failure, the
+ link to the child will not be lost, but it could be linked at both the old
+ and new locations.
+
+ The source link should not be the same as any link (directory and child name)
+ in the ``to_dir`` path. This restriction is not enforced, but it may be
+ enforced in a future version. If it were violated then the result would be
+ to create a cycle in the directory structure that is not necessarily reachable
+ from the root of the destination path (``$NEWDIRCAP``), which could result in
+ data loss, as described in ticket `#943`_.
+
+.. _`#943`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/943
+
Other Utilities
---------------
functionality described above, with the provided $CHILDNAME present in the
'from_name' field of that form. I.e. this presents a form offering to
rename $CHILDNAME, requesting the new name, and submitting POST rename.
+ This same URL format can also be used with "move-form" with the expected
+ results.
``GET /uri/$DIRCAP/[SUBDIRS../]CHILDNAME?t=uri``
count-shares-good: the number of good shares that were found
count-shares-needed: 'k', the number of shares required for recovery
count-shares-expected: 'N', the number of total shares generated
- count-good-share-hosts: this was intended to be the number of distinct
- storage servers with good shares. It is currently
- (as of Tahoe-LAFS v1.8.0) computed incorrectly;
- see ticket #1115.
+ count-good-share-hosts: the number of distinct storage servers with
+ good shares. Note that a high value does not
+ necessarily imply good share distribution,
+ because some of these servers may only hold
+ duplicate shares.
count-wrong-shares: for mutable files, the number of shares for
versions other than the 'best' one (highest
sequence number, highest roothash). These are
- either old ...
+ either old, or created by an uncoordinated or
+ not fully successful write.
count-recoverable-versions: for mutable files, the number of
recoverable versions of the file. For
a healthy file, this will equal 1.
projects / tahoe-lafs / tahoe-lafs.git / blobdiff