From 72268f2bfe7d0bba9a4cc723d0cd74815eabc08d Mon Sep 17 00:00:00 2001
From: Zooko O'Whielacronx <zooko@zooko.com>
Date: Fri, 22 Aug 2008 08:46:05 -0700
Subject: [PATCH] docs: warn that the "garbage-collection and accounting"
 section of architecture.txt is out of date, and clarify that "deleted"
 therein means ciphertext getting garbage-collected

---
 docs/architecture.txt | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/docs/architecture.txt b/docs/architecture.txt
index 5da4e250..07a6992c 100644
--- a/docs/architecture.txt
+++ b/docs/architecture.txt
@@ -313,6 +313,8 @@ creation of a "virtual CD" as easily as dragging a folder onto a user icon.
 
 LEASES, REFRESHING, GARBAGE COLLECTION, QUOTAS
 
+THIS SECTION IS OUT OF DATE.  Since we wrote this we've changed our minds about how we intend to implement these features.  Neither the old design, documented below, nor the new one, documented on the tahoe-dev mailing list and the wiki and the issue tracker, have actually been implemented yet.
+
 Shares are uploaded to a storage server, but they do not necessarily stay
 there forever. We are anticipating three main share-lifetime management modes
 for Tahoe: 1) per-share leases which expire, 2) per-account timers which
@@ -401,7 +403,10 @@ each lease is always set to zero). In addition, many features have not been
 implemented yet: the client should claim leases on files which are added to
 the vdrive by linking (as opposed to uploading), and the client should cancel
 leases on files which are removed from the vdrive, but neither has been
-written yet. This means that shares are not ever deleted in this release.
+written yet. This means that shares are not ever deleted in this
+release. (Note, however, that if read-cap to a file is deleted then it will no
+longer be possible to decrypt that file, even if the shares which contain
+the erasure-coded ciphertext still exist.)
 
 
 FILE REPAIRER
-- 
2.45.2