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

3 files changed, 56 insertions, 0 deletions

diff --git a/doc/bugs/Possible_data-loss_if_WORM_keys_do_not_encode_relative_paths.mdwn b/doc/bugs/Possible_data-loss_if_WORM_keys_do_not_encode_relative_paths.mdwn
new file mode 100644
index 000000000..2b3cf3f2f
--- /dev/null
+++ b/doc/bugs/Possible_data-loss_if_WORM_keys_do_not_encode_relative_paths.mdwn
@@ -0,0 +1,23 @@
+This is a follow-up to [this
+qbug](http://git-annex.branchable.com/bugs/WORM_keys_differ_depending_on_working_dir_during_add/).
+Thank you for your fix there! However, if I understood correctly, you
+indicated in your reply that the current fix completely removes the
+relative path component from WORM keys. I gave some thought to this
+and believe not having the relative path encoded inside WORM keys
+makes key collisions (and accordingly data-loss) a very dire problem,
+while they are not of practical concern if the relative path is
+encoded.
+
+When relative paths are encoded within the key, a collision can only
+occur when a file in the same directory is annexed twice within the
+resolution of the mtime component inside the key (i.e., one second).
+As such, unless one adds files automatically with a period of < 1s,
+one can very much be certain that no collisions come up.
+
+Without relative paths, however, one could never be certain that
+adding a file will not result in data-loss.
+
+Instead of just using the basename, WORM keys could be kept stable by
+using the relative path and anchoring it to the root of the
+repository.
+
diff --git a/doc/bugs/whereis_does_not_work_in_direct_mode/comment_3_44dd6e0c6e7a7abd6483a4367baa7f0f._comment b/doc/bugs/whereis_does_not_work_in_direct_mode/comment_3_44dd6e0c6e7a7abd6483a4367baa7f0f._comment
new file mode 100644
index 000000000..6fb3b8046
--- /dev/null
+++ b/doc/bugs/whereis_does_not_work_in_direct_mode/comment_3_44dd6e0c6e7a7abd6483a4367baa7f0f._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://svario.it/gioele"
+ nickname="gioele"
+ subject="comment 3"
+ date="2014-08-13T06:36:52Z"
+ content="""
+This is strange: I can replicate the problem on three different Ubuntu machines (12.04.5 32 and 64 bit, 14.04 64 bit) using that script.
+
+I attached to the gist [the execution log in direct mode](https://gist.github.com/gioele/dde462df89edfe17c5e3#file-annex-direct-log) (where the bug is shown), the [log in indirect mode](https://gist.github.com/gioele/dde462df89edfe17c5e3#file-annex-indirect-log) (where the bug does not appear), and a [diff between the two](https://gist.github.com/gioele/dde462df89edfe17c5e3#file-log-diff). I hope this helps.
+"""]]
diff --git a/doc/bugs/whereis_does_not_work_in_direct_mode/comment_4_f334a85d6dd6c4971f0609ae0831766a._comment b/doc/bugs/whereis_does_not_work_in_direct_mode/comment_4_f334a85d6dd6c4971f0609ae0831766a._comment
new file mode 100644
index 000000000..ffbbcc12a
--- /dev/null
+++ b/doc/bugs/whereis_does_not_work_in_direct_mode/comment_4_f334a85d6dd6c4971f0609ae0831766a._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="http://svario.it/gioele"
+ nickname="gioele"
+ subject="comment 4"
+ date="2014-08-13T06:40:12Z"
+ content="""
+Talking about the three possible causes for this bug,
+
+> 1) pc1 has not pushed git-annex branch to origin (or pushed it after pc2 pulled)
+
+pc1 pushes using `git annex sync -c annex.alwayscommit=true origin`. This should be enough, isn't it?
+
+> 2) pc2 has not fetched git-annex branch from origin
+
+The pc2 repository is created with `git clone localhost:/tmp/annex/Docs.git`, so there branches should all be there. I tried adding a `git fetch --all` to the script but it makes no difference. This is the list of branches in pc2:
+
+    * master
+      remotes/origin/HEAD -> origin/master
+      remotes/origin/master
+      remotes/origin/synced/git-annex
+      remotes/origin/synced/master
+
+"""]]