From a2f34b4e1a36a70333019825c7f6f73e69c91da0 Mon Sep 17 00:00:00 2001
From: Zooko O'Whielacronx <zooko@zooko.com>
Date: Mon, 13 Apr 2009 09:08:37 -0700
Subject: [PATCH] docs: a few edits/updates about dirnodes

---
 docs/specifications/dirnodes.txt | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/docs/specifications/dirnodes.txt b/docs/specifications/dirnodes.txt
index 7023f86c..dff41ecd 100644
--- a/docs/specifications/dirnodes.txt
+++ b/docs/specifications/dirnodes.txt
@@ -238,7 +238,7 @@ How well does this design meet the goals?
      
 
 
-=== Confidentiality leaks in the vdrive server ===
+=== Confidentiality leaks in the storage servers ===
 
 Dirnode (and the mutable files upon which they are based) are very private
 against other clients: traffic between the client and the storage servers is
@@ -259,7 +259,7 @@ attacker may be able to build up a graph with the same shape as the plaintext
 filesystem, but with unlabeled edges and unknown file contents.
 
 
-=== Integrity failures in the vdrive server ===
+=== Integrity failures in the storage servers ===
 
 The mutable file's integrity mechanism (RSA signature on the hash of the file
 contents) prevents the storage server from modifying the dirnode's contents
@@ -268,8 +268,8 @@ unavailable, but not corrupt it.
 
 A sufficient number of colluding storage servers can perform a rollback
 attack: replace all shares of the whole mutable file with an earlier version.
-TODO: To prevent this, when retrieving the contents of a mutable file, the
-client should query more servers than necessary and use the highest available
+To prevent this, when retrieving the contents of a mutable file, the
+client queries more servers than necessary and uses the highest available
 version number. This insures that one or two misbehaving storage servers
 cannot cause this rollback on their own.
 
-- 
2.45.2