response

1 files 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]]