From 5926be6f307c03f5ed1a02dffff5dce0d987e689 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Wed, 7 Dec 2011 12:36:15 -0400 Subject: response --- ...sing_rsync_remotes_with_encryption_enabled.mdwn | 22 +++++++++++++++++----- 1 file changed, 17 insertions(+), 5 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 d727d6917..93588b49c 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 @@ -4,14 +4,14 @@ git-annex version was 3.20111111 > "once again" ? When did it do it before? -It's the second time i uploaded all the files to an encrypted rsync remote and git-annex is not able to find it anymore. --[[gebi]] +>> It's the second time i uploaded all the files to an encrypted rsync remote and git-annex is not able to find it anymore. --[[gebi]] > "lost" ? How is the remote lost? -git-annex is not able to find any files on the encrypted rsync remote anymore. -Copy does not copy the content again but drop doesn't find it, thus it's somehow "lost" and in an strange state. -I've also had the state where the content was already on the remote side but git-annex copy would copy it again, -ignoring all the data on the remote side. --[[gebi]] +>> git-annex is not able to find any files on the encrypted rsync remote anymore. +>> Copy does not copy the content again but drop doesn't find it, thus it's somehow "lost" and in an strange state. +>> I've also had the state where the content was already on the remote side but git-annex copy would copy it again, +>> ignoring all the data on the remote side. --[[gebi]] Both *remoteserver* and *localserver* are rsync remotes with enabled encryption. All commands are executed on the git repository on my laptop. @@ -64,3 +64,15 @@ I thought that *copy* would verify that, but seems not. > What happens if you copy the data to remoteserver again? --[[Joey]] The commands above are executed within a few seconds and completely repeatable. --[[gebi]] + +> In that case, why don't you run the commands with `-d` to see the actual +> rsync command it's running to check if the content is present. +> Then you can try repeatedly running the command by hand and see why it +> sometimes succeeds and sometimes fail. +> +> The command will be something like this: +> `rsync --quiet hostname:/dir/file 2>/dev/null` +> +> The exit status is what's used to see if content is present -- and +> currently any failure even a failure to connect is taken to mean it's not +> present. --[[Joey]] -- cgit v1.2.3