Merge branch 'master' into p2p_locking

diff --cc doc/todo/P2P_locking_connection_drop_safety.mdwn
index d60a80996320d351bbc09fa5e5f0247128cadf0f,a45002030ebdce106b6a736d9813cc6d06f7ceb4..418ae040662365bdbff22d0f3eb125014dc7c5ff
--- 1/doc/todo/P2P_locking_connection_drop_safety.mdwn
--- 2/doc/todo/P2P_locking_connection_drop_safety.mdwn
+++ b/doc/todo/P2P_locking_connection_drop_safety.mdwn
@@@ -62,7 -63,51 +63,52 @@@ git-annex gets installed, a user is lik
  
  OTOH putting the timestamp in the lock file may be hard (eg on Windows).
  
- > Status: Content retention files implemented. P2P LOCKCONTENT uses a 10
- > minute retention in case it gets killed. Need to implement PRE-REMOVE.
+ > Status: Content retention files implemented on `p2p_locking` branch.
+ > P2P LOCKCONTENT uses a 10 minute retention in case it gets killed,
+ > but other values can be used in the future safely.
  
- --[[Joey]]
+ ----
+ 
+ Extending the P2P protocol is a bit tricky, because the same P2P
+ protocol connection could be used for several different things at
+ the same time. A PRE-REMOVE N Key might be followed by removals of other
+ keys, and eventually a removal of the requested key. There are
+ sometimes pools of P2P connections that get used like this.
+ So the server would need to cache some number of PRE-REMOVE timestamps.
+ How many?
+ 
+ Certainly care would need to be taken to send PRE-REMOVE to the same
+ connection as REMOVE. How?
+ 
+ Could this be done without extending the REMOVE side of the P2P protocol?
+ 
+ 1. check start time
+ 2. LOCKCONTENT
+ 3. prepare to remove
+ 4. in checkVerifiedCopy, 
+    check current time.. fail if more than 10 minutes from start
+ 5. REMOVE
+ 
+ The issue with this is that git-annex could be paused for any amount of
+ time between steps 4 and 5. Usually it won't pause.. 
+ mkSafeDropProof calls checkVerifiedCopy and constructs the proof,
+ and then it immediately sends REMOVE. But of course sending REMOVE
+ could take arbitrarily long. Or git-annex could be paused at just the wrong
+ point.
+ 
+ Ok, let's reconsider... Add GETTIMESTAMP which causes the server to
+ return its current timestamp. The same timestamp must be returned on any
+ connection to the server, eg the server must have a single clock.
+ That can be called before LOCKCONTENT.
+ Then REMOVE Key Timestamp can fail if the current time is past the
+ specified timestamp. 
+ 
+ How to handle this when proxying to a cluster? In a cluster, each node
+ has a different clock. So GETTIMESTAMP will return a bunch of times.
+ The cluster can get its own current time, and return that to the client.
+ Then REMOVE Key Timestamp can have the timestamp adjusted when it's sent
+ out to each client, by calling GETTIMESTAMP again and applying the offsets
+ between the cluster's clock and each node's clock.
+ 
+ This approach would need to use a monotonic clock!
++>>>>>>> master