docs: corrections and clarifications.

docs/backupdb.rst

@@ -52,7 +52,7 @@ The database contains the following tables::
   
   CREATE TABLE local_files
   (
-   path  varchar(1024),  PRIMARY KEY -- index, this is os.path.abspath(fn)
+   path  varchar(1024),  PRIMARY KEY -- index, this is an absolute UTF-8-encoded local filename
    size  integer,         -- os.stat(fn)[stat.ST_SIZE]
    mtime number,          -- os.stat(fn)[stat.ST_MTIME]
    ctime number,          -- os.stat(fn)[stat.ST_CTIME]
@@ -91,7 +91,8 @@ The first step is to convert the path to an absolute form
 is not present in this table, the file must be uploaded. The upload process
 is:
 
-1. record the file's size, creation time, and modification time
+1. record the file's size, ctime (which is the directory-entry change time or
+   file creation time depending on OS) and modification time
 
 2. upload the file into the grid, obtaining an immutable file read-cap
 

docs/frontends/CLI.rst

@@ -120,9 +120,9 @@ contact that node instead of a local one.
 These commands also use a table of "aliases" to figure out which directory
 they ought to use a starting point. This is explained in more detail below.
 
-As of Tahoe-LAFS v1.7 (v1.7.1 on Windows), passing non-ASCII characters to the
+As of Tahoe-LAFS v1.7.0 (v1.8.0 on Windows), passing non-ASCII characters to
-CLI should work. On Unix, the command-line arguments are assumed to use the
+the CLI should work. On Unix, the command-line arguments are assumed to use
-character encoding specified by the current locale.
+the character encoding specified by the current locale.
 
 Starting Directories
 --------------------

docs/garbage-collection.rst

@@ -35,13 +35,14 @@ of duration-over-renewal-time will be more robust in the face of occasional
 delays or failures.
 
 The current recommended values for a small Tahoe grid are to renew the leases
-once a week, and to give each lease a duration of 31 days. Renewing leases
+once a week, and give each lease a duration of 31 days. In the current
-can be expected to take about one second per file/directory, depending upon
+release, there is not yet a way to create a lease with a different duration,
-the number of servers and the network speeds involved. Note that in the
+but the server can use the ``expire.override_lease_duration`` configuration
-current release, the server code enforces a 31 day lease duration: there is
+setting to increase or decrease the effective duration (when the lease is
-not yet a way for the client to request a different duration (however the
+processed) to something other than 31 days.
-server can use the "expire.override_lease_duration" configuration setting to
+
-increase or decrease the effective duration to something other than 31 days).
+Renewing leases can be expected to take about one second per file/directory,
+depending upon the number of servers and the network speeds involved.
 
 Client-side Renewal
 ===================
@@ -65,13 +66,13 @@ Note that newly uploaded files (and newly created directories) get an initial
 lease too: the ``--add-lease`` process is only needed to ensure that all
 older objects have up-to-date leases on them.
 
-For larger systems (such as a commercial grid), a separate "maintenance
+A separate "rebalancing manager/service" is also planned -- see ticket
-daemon" is under development. This daemon will acquire manifests from
+`#543 <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/543>`_. The exact
-rootcaps on a periodic basis, keep track of checker results, manage
+details of what this service will do are not settled, but it is likely to
-lease-addition, and prioritize repair needs, using multiple worker nodes to
+work by acquiring manifests from rootcaps on a periodic basis, keeping track
-perform these jobs in parallel. Eventually, this daemon will be made
+of checker results, managing lease-addition, and prioritizing repair and
-appropriate for use by individual users as well, and may be incorporated
+rebalancing of shares. Eventually it may use multiple worker nodes to perform
-directly into the client node.
+these jobs in parallel.
 
 Server Side Expiration
 ======================
@@ -170,9 +171,7 @@ The ``tahoe.cfg`` file uses the following keys to control lease expiration:
     This key is meant to compensate for the fact that clients do not yet have
     the ability to ask for leases that last longer than 31 days. A grid which
     wants to use faster or slower GC than a 31-day lease timer permits can
-    use this parameter to implement it. The current fixed 31-day lease
+    use this parameter to implement it.
-    duration makes the server behave as if "lease.override_lease_duration =
-    31days" had been passed.
 
     This key is only valid when age-based expiration is in use (i.e. when
     ``expire.mode = age`` is used). It will be rejected if cutoff-date