From 6f221f1fc3647de5b28179574125f6caa211fe0c Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Tue, 6 Dec 2011 17:06:08 -0400 Subject: response --- ...nnex_losing_rsync_remotes_with_encryption_enabled.mdwn | 15 +++++++++++++++ 1 file changed, 15 insertions(+) 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]] -- cgit v1.2.3