"Checking" is the act of asking storage servers whether they have a share for
the given file or directory: if there are not enough shares available, the
file/directory will be unrecoverable. "Verifying" is the act of downloading
-or cryptographically asserting that the server's share is undamaged: it
+and/or cryptographically asserting that the server's share is undamaged: it
requires more work (bandwidth and CPU) than checking, but can catch problems
that simple checking cannot. "Repair" is the act of replacing missing/damaged
shares with new ones.
hardware failures, serious software bugs, or malice on the part of the
storage server operator, so a corrupted share should be considered highly
unusual. The "incident gatherer" mechanism will automatically report share
-corruption to an incident gatherer service, if one is pre-configured.
+corruption to an incident gatherer service, if one is configured.
By periodically checking/repairing all files and directories, objects in the
Tahoe filesystem remain resistant to recoverability failures due to missing
results page that summarizes any problems that were encountered. All
long-running deep-traversal operations, including deep-check, use a
start-and-poll mechanism, to avoid depending upon a single long-lived HTTP
-connection. docs/webapi.txt has details.
+connection. docs/frontends/webapi.txt has details.
** Configuration Changes: single INI-format tahoe.cfg file
This release adds the 'tahoe create-alias' command, which is a combination of
'tahoe mkdir' and 'tahoe add-alias'. This also allows you to start using a
new tahoe directory without exposing its URI in the argv list, which is
-publically visible (through the process table) on most unix systems.
+publicly visible (through the process table) on most unix systems.
The single-argument form of "tahoe put" was changed to create an unlinked
file. I.e. "tahoe put bar.txt" will take the contents of a local "bar.txt"
lifted. This release knows how to handle so-called "v2 immutable shares",
which permit immutable files of up to about 18 EiB (about 3*10^14). These v2
shares are not yet created by default, so that files created with tahoe-1.3.0
-can still be read by earlier versions. In the subsequent release we will
-switch to generating v2 shares, so that files created with tahoe-1.4.0 can be
-read by tahoe-1.3.0 and later. Note that the storage server must also be
-changed to support files larger than 12GiB, and that these changes have not
-yet been implemented. (ticket #346)
+can still be read by earlier versions. In the next release we will switch to
+generating v2 shares, so that files created with tahoe-1.4.0 can be read by
+tahoe-1.3.0 and later. Note that the storage server must also be changed to
+support files larger than 12GiB, and that these changes have not yet been
+implemented. (ticket #346)
Tahoe now uses Foolscap "Incidents", writing an "incident report" file to
logs/incidents/ each time something weird occurs. These reports are available
The 'nickname' setting is now defined to be a UTF-8 -encoded string, allowing
non-ascii nicknames.
-The 'tahoe start' command will now pass a --syslog argument through to
-twistd, making it easier to launch non-Tahoe nodes (like the cpu-watcher) and
-have them log to syslogd instead of a local file. This is useful when running
-a Tahoe node out of a USB flash drive.
+The 'tahoe start' command will now accept a --syslog argument and pass it
+through to twistd, making it easier to launch non-Tahoe nodes (like the
+cpu-watcher) and have them log to syslogd instead of a local file. This is
+useful when running a Tahoe node out of a USB flash drive.
Tahoe now includes experimental FTP and SFTP servers. When configured with a
suitable method to translate username+password into a root directory cap, it
projects / tahoe-lafs / tahoe-lafs.git / commitdiff