followup

1 files changed, 26 insertions, 0 deletions

diff --git a/doc/bugs/Hybrid_encryption_can__39__t_generate_the_right_key_after_moving_files/comment_5_ce0342e38a87017ad58c9a79b17d759a._comment b/doc/bugs/Hybrid_encryption_can__39__t_generate_the_right_key_after_moving_files/comment_5_ce0342e38a87017ad58c9a79b17d759a._comment
new file mode 100644
index 000000000..d20a6e6a1
--- /dev/null
+++ b/doc/bugs/Hybrid_encryption_can__39__t_generate_the_right_key_after_moving_files/comment_5_ce0342e38a87017ad58c9a79b17d759a._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2017-06-09T17:04:09Z"
+ content="""
+"I think what is happening is that my small file I was testing with somehow
+became corrupted or was modified while on Amazon's servers."
+
+That was also kind of my guess. It's hard to imagine how
+the way that a file is downloaded from The Cloud changes
+how git-annex decrypts it. As long as the content is the same,
+the decrpytion step should behave identially no matter where
+the file is downloaded from.
+
+But, multiple small files getting corrupted seems like it must
+have a cause other than a bit flip. Perhaps something about how
+they were transferred between the two clouds corrupted them..
+
+I suppose there could also be a bug in git-annex or rclone that somehow
+corrupts uploads of small files. Perhaps something to do with chunking..
+What does `git annex info theremote --fast` say about its configuration?
+
+What is the range of sizes of small files that you've found to be
+corrupted? Is there a cut-off point after which all larger files are
+not corrupted? Are any small files not corrupted?
+"""]]