mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

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

Browse source
This commit is contained in:
Joey Hess 2013-05-23 13:55:25 -04:00
commit ff3640acad
3 changed files with 41 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

25
doc/bugs/Glacier_remote_uploads_duplicates/comment_1_8aef582a0f0d0c7f764b425fc45de3b4._comment Normal file
View file

@ -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.
"""]]

8
doc/bugs/Glacier_remote_uploads_duplicates/comment_2_150ce8b7c4424a83c4b1760da5a89d27._comment Normal file
View file

@ -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.
"""]]

8
doc/bugs/Glacier_remote_uploads_duplicates/comment_3_718af5048c5f894eee134547a2e0a644._comment Normal file
View file

@ -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.)
"""]]