mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

thoughts on safer direct mode transfers

Browse source
This commit is contained in:
Joey Hess 2013-01-08 13:44:38 -04:00
parent 174867b846
commit 5f6c33e50c
1 changed files with 28 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

28
doc/design/assistant/desymlink.mdwn
View file

@ -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 * Deal with files changing as they're being transferred from a direct mode
repository to another git repository. The remote repo currently will 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. 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. * 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 This doesn't affect OSX, which uses FSEvents now, but it makes direct
mode assistant not 100% on other BSD's. mode assistant not 100% on other BSD's.