Merge branch 'master' of ssh://git-annex.branchable.com

3 files changed, 41 insertions, 0 deletions

diff --git a/doc/bugs/Glacier_remote_uploads_duplicates/comment_1_8aef582a0f0d0c7f764b425fc45de3b4._comment b/doc/bugs/Glacier_remote_uploads_duplicates/comment_1_8aef582a0f0d0c7f764b425fc45de3b4._comment
new file mode 100644
index 000000000..9e42d4cae
--- /dev/null
+++ b/doc/bugs/Glacier_remote_uploads_duplicates/comment_1_8aef582a0f0d0c7f764b425fc45de3b4._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 1"
+ date="2013-05-23T15:55:16Z"
+ content="""
+Please beware of the warning on the man page when using --trust-glacier-inventory:
+
+> Be careful using this, especially if you or someone  else  might
+> have  recently  removed  a file from Glacier. If you try to drop
+> the only other copy of the file, and this switch is enabled, you
+> could lose data!
+
+While I'm inclined to want git-annex to store the necessary mappings from keys to glacier IDs in the git-annex branch, which would allow uploads/downloads from multiple repositories to the same glacier repository, it will not help with this problem. The git-annex branch can be out of date too.
+
+It seems that what's needed is a separate form of the checkpresent hook, that's used when deciding whether to copy data to glacier.
+We want this to trust the glacier inventory. But we don't want to trust the glacier inventory when moving data to glacier, or when running `git annex drop`! (unless --trust-glacier-inventory is specified). I think this would be easy to add. If you're up for testing a patch, I could do it today.
+
+BTW, there does seem to be a workaround that avoids duplicate copies to glacier:
+
+    git annex copy --to glacier --not --in glacier
+
+While normally copy checks the inventory to see if a key has been sent to glacier, and so will re-send, the `--not --in glacier`
+trusts the location tracking information, so if git-annex has sent the key before, it will skip the copy.
+"""]]
diff --git a/doc/bugs/Glacier_remote_uploads_duplicates/comment_2_150ce8b7c4424a83c4b1760da5a89d27._comment b/doc/bugs/Glacier_remote_uploads_duplicates/comment_2_150ce8b7c4424a83c4b1760da5a89d27._comment
new file mode 100644
index 000000000..859377308
--- /dev/null
+++ b/doc/bugs/Glacier_remote_uploads_duplicates/comment_2_150ce8b7c4424a83c4b1760da5a89d27._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 2"
+ date="2013-05-23T15:57:08Z"
+ content="""
+I suppose another way to fix it along similar lines would be to make `git annex copy` always trust location tracking information when deciding whether to copy. I'm not sure how I feel about this though -- it might make things less robust in situations where `git annex copy` is run as a backup, and location tracking could have gotten out of date.
+"""]]
diff --git a/doc/bugs/Glacier_remote_uploads_duplicates/comment_3_718af5048c5f894eee134547a2e0a644._comment b/doc/bugs/Glacier_remote_uploads_duplicates/comment_3_718af5048c5f894eee134547a2e0a644._comment
new file mode 100644
index 000000000..4091e258c
--- /dev/null
+++ b/doc/bugs/Glacier_remote_uploads_duplicates/comment_3_718af5048c5f894eee134547a2e0a644._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 3"
+ date="2013-05-23T15:59:37Z"
+ content="""
+It's also worth noting that the assistant always trusts the location log when deciding whether to send a key to a remote. So I think it will not trigger this bug. It seems only `git annex copy` will. (Well, maybe `git annex move` too in an edge case.)
+"""]]