thoughts on safer direct mode transfers

doc/design/assistant/desymlink.mdwn

@@ -87,6 +87,34 @@ is converted to a real file when it becomes present.
 * Deal with files changing as they're being transferred from a direct mode
   repository to another git repository. The remote repo currently will 
   accept the bad data and update the location log to say it has the key.
+
+  This affects both special remotes and git remotes. 
+
+  For special remotes,
+  it seems the best that could be done is to have an error unwind action
+  passed to `sendAnnex` that is called if the file is modified as it's
+  transferred. That would then remove the probably corrupted file from the
+  remote. (The full transfer would still run, unless there was also a way
+  to cancel an in progress transfer.)
+
+  With the above, there is some potential for the bed content being
+  downloaded from the special remote into another repo. This would only
+  happen if the other repo for some reason thinks the special remote 
+  has the content. Since the location log would not be updated until the
+  transfer is successful, this should not happen.
+
+  For git remotes, add a flag to `git-annex-shell recvkey` (using a field
+  after the "--" to remain back-compat). With this flag, after receiving
+  the data, the remote should wait for a signal that the data is good
+  before it updates the location log. The signal could just be a "1"
+  sent over the ssh channel. Or another `git-annex-shell` command.
+
+  Also `git-annex-shell sendkey` needs to do something if it sent bad
+  data. This seems to not need protocol changes; it can just detect 
+  the problem and exit nonzero. Would need to do something to clean up
+  the temp file, which is probably corrupt. (Could in future use it as a
+  basis for transferring the new key..)
+
 * kqueue does not deliver an event when an existing file is modified.
   This doesn't affect OSX, which uses FSEvents now, but it makes direct
   mode assistant not 100% on other BSD's.