*** Immutable Directories
-Tahoe-LAFS can now create and handle immutable directories (#607). These are
-read just like normal directories, but are "deep-immutable", meaning that all
-their children (and everything reachable from those children) must be immutable
-objects (i.e. immutable/literal files, and other immutable directories).
-
-These directories must be created in a single webapi call, which provides all
-of the children at once (instead of the usual create/add/add sequence, since
-they cannot be changed after creation). They have URIs that start with
+Tahoe-LAFS can now create and handle immutable directories. (#607, #833, #931)
+These are read just like normal directories, but are "deep-immutable", meaning
+that all their children (and everything reachable from those children) must be
+immutable objects (i.e. immutable or literal files, and other immutable
+directories).
+
+These directories must be created in a single webapi call that provides all
+of the children at once. (Since they cannot be changed after creation, the
+usual create/add/add sequence cannot be used.) They have URIs that start with
"URI:DIR2-CHK:" or "URI:DIR2-LIT:", and are described on the human-facing web
interface (aka the "WUI") with a "DIR-IMM" abbreviation (as opposed to "DIR"
for the usual read-write directories and "DIR-RO" for read-only directories).
(in previous releases, it created read-only mutable directories) (#828). This
is significantly faster, since it does not need to create an RSA keypair for
each new directory. Also "DIR-IMM" immutable directories are repairable, unlike
-"DIR-RO" read-only mutable directories (at least in this release: a future
-Tahoe-LAFS release should be able to repair DIR-RO).
+"DIR-RO" read-only mutable directories at present. (A future Tahoe-LAFS release
+should also be able to repair DIR-RO.)
In addition, the backupdb (used by "tahoe backup" to remember what it has
already copied) has been enhanced to store information about existing immutable
directories. This allows it to re-use directories that have moved but still
-contain identical contents, or which have been deleted and later replaced. (the
+contain identical contents, or that have been deleted and later replaced. (The
1.5.0 "tahoe backup" command could only re-use directories that were in the
-same place as they were in the immediately previous backup). With this change,
+same place as they were in the immediately previous backup.) With this change,
the backup process no longer needs to read the previous snapshot out of the
-Tahoe-LAFS grid, reducing the network load considerably.
+Tahoe-LAFS grid, reducing the network load considerably. (#606)
A "null backup" (in which nothing has changed since the previous backup) will
require only two Tahoe-side operations: one to add an Archives/$TIMESTAMP
size of your directories. After this initial pass, all subsequent passes
should take a tiny fraction of the time.
-As noted above, Tahoe-LAFS versions earlier than 1.5.0 cannot read immutable
-directories.
+As noted above, Tahoe-LAFS versions earlier than 1.5.0 cannot list a directory
+containing an immutable subdirectory. Tahoe-LAFS versions earlier than 1.6.0
+cannot read the contents of an immutable directory.
The "tahoe backup" command has been improved to skip over unreadable objects
(like device files, named pipes, and files with permissions that prevent the
that you are creating a general-purpose Tahoe-LAFS "node" process, which has
several components that can be activated. Storage service is one of these
optional components, as is the Helper, FTP server, and SFTP server. Web gateway
-functionality is nominally on this list, but it is always active: a future
+functionality is nominally on this list, but it is always active; a future
release will make it optional. There are three special purpose servers that
can't currently be run as a component in a node: introducer, key-generator,
-stats-gatherer.
+and stats-gatherer.
So now "tahoe create-node" will create a Tahoe-LAFS node process, and after
creation you can edit its tahoe.cfg to enable or disable the desired
storage service. It is equivalent to "tahoe create-node --no-storage". This
helps to reduce the confusion surrounding the use of a command with "client" in
its name to create a storage *server*. Use "tahoe create-client" to create a
-purely client-side node. If you want to offer storage to the grid, use "tahoe
-create-node" instead.
+purely client-side node. If you want to offer storage to the grid, use
+"tahoe create-node" instead.
In the future, other services will be added to the node, and they will be
-controlled through options in tahoe.cfg . The most important of these services
-may get additional --enable-XYZ or --disable-XYZ arguments to "tahoe
-create-node".
+controlled through options in tahoe.cfg . The most important of these
+services may get additional --enable-XYZ or --disable-XYZ arguments to
+"tahoe create-node".
** Performance Improvements
particularly important if there is a server on the grid that is extremely slow
or even hung in such a way that it will never respond. In previous releases
such a server would have a negative impact on all downloads from that grid. In
-this release, such a server will have no impact on downloads (as long as K
-shares can be found on other, quicker, servers.) This also means that
+this release, such a server will have no impact on downloads, as long as K
+shares can be found on other, quicker, servers. This also means that
downloads now use the "best-alacrity" servers that they talk to, as measured by
how quickly the servers reply to the initial query. This might cause downloads
to go faster, especially on grids with heterogeneous servers or geographical
The webapi acquired a new "t=mkdir-with-children" command, to create and
populate a directory in a single call. This is significantly faster than
using separate "t=mkdir" and "t=set-children" operations (it uses one
-gateway-to-grid roundtrip, instead of three or four).
+gateway-to-grid roundtrip, instead of three or four). (#533)
The t=set-children (note the hyphen) operation is now documented in
docs/frontends/webapi.txt, and is the new preferred spelling of the old
t=set_children (with an underscore). The underscore version remains for
-backwards compatibility.
+backwards compatibility. (#381, #927)
The tracebacks produced by errors in CLI tools should now be in plain text,
instead of HTML (which is unreadable outside of a browser). (#646)
The [storage]reserved_space configuration knob (which causes the storage
server to refuse shares when available disk space drops below a threshold)
-should work on windows now, not just unix. (#637)
+should work on Windows now, not just UNIX. (#637)
"tahoe cp" should now exit with status "1" if it cannot figure out a suitable
target filename, such as when you copy from a bare filecap. (#761)
"tahoe deep-check --repair" should tolerate repair failures now, instead of
halting traversal. (#874, #786)
+"tahoe create-alias" no longer corrupts the aliases file if it had
+previously been edited to have no trailing newline. (#741)
+
Many small packaging improvements were made to facilitate the "tahoe-lafs"
package being included in Ubuntu. Several mac/win32 binary libraries were
removed, some figleaf code-coverage files were removed, a bundled copy of
Several DeprecationWarnings for python2.6 were silenced. (#859)
+The checker --add-lease option would sometimes fail for shares stored
+on old (Tahoe v1.2.0) servers. (#875)
+
+The documentation for installing on Windows (docs/install.html) has been
+improved. (#773)
+
+For other changes not mentioned here, see
+<http://allmydata.org/trac/tahoe/query?milestone=1.6.0&keywords=!~news-done>.
+To include the tickets mentioned above, go to
+<http://allmydata.org/trac/tahoe/query?milestone=1.6.0>.
+
* Release 1.5.0 (2009-08-01)
projects / tahoe-lafs / tahoe-lafs.git / commitdiff