diff options
| author |  Joey Hess <joey@kitenet.net> | 2011-12-06 17:06:08 -0400 |
|---|---|---|
| committer | Joey Hess <joey@kitenet.net> | 2011-12-06 17:06:08 -0400 |
| commit | 6f221f1fc3647de5b28179574125f6caa211fe0c (patch) | |
| tree | 9287023a9333505e32926e4b66572a1ccaa1aca9 | |
| parent | adb1dc65bc9342d76d641fa06ec187f3e2c7b783 (diff) | |
response
| -rw-r--r-- | doc/bugs/git-annex_losing_rsync_remotes_with_encryption_enabled.mdwn | 15 |
1 files changed, 15 insertions, 0 deletions
diff --git a/doc/bugs/git-annex_losing_rsync_remotes_with_encryption_enabled.mdwn b/doc/bugs/git-annex_losing_rsync_remotes_with_encryption_enabled.mdwn index 105e24aac..914b45d18 100644 --- a/doc/bugs/git-annex_losing_rsync_remotes_with_encryption_enabled.mdwn +++ b/doc/bugs/git-annex_losing_rsync_remotes_with_encryption_enabled.mdwn @@ -1,5 +1,9 @@ Somehow git-annex has again lost a complete rsync remote with encryption enabled... +> "once again" ? When did it do it before? + +> "lost" ? How is the remote lost? + Both *remoteserver* and *localserver* are rsync remotes with enabled encryption. All commands are executed on the git repository on my laptop. Target of origin is a gitolite repository without annex support (thus the two rsync remotes). @@ -38,3 +42,14 @@ I thought that *copy* would verify that, but seems not. % g a fsck tools fsck tools/md5_sha1_utility.exe (checksum...) ok fsck tools/win32diskimager-RELEASE-0.2-r23-win32.zip (checksum...) ok + +> Copy does do an explicit check that the content is present on remoteserver, +> and based on the above, the content was found to be already there, +> which is why it did not copy it again. +> +> Drop does an indentical check that the content is present, and +> since it failed to find it, I am left thinking something must have +> happened to the remove in between the copy and the drop to cause the +> content to go away. +> +> What happens if you copy the data to remoteserver again? --[[Joey]] |