From 8bc7dd025bb61c0c7af7d2c2b28c4091b51480f1 Mon Sep 17 00:00:00 2001 From: "http://svario.it/gioele" Date: Wed, 13 Aug 2014 06:36:53 +0000 Subject: Added a comment --- .../comment_3_44dd6e0c6e7a7abd6483a4367baa7f0f._comment | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 doc/bugs/whereis_does_not_work_in_direct_mode/comment_3_44dd6e0c6e7a7abd6483a4367baa7f0f._comment (limited to 'doc') 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. +"""]] -- cgit v1.2.3 From 20a7f85518e1a22616cb6d297c867829f8bb35af Mon Sep 17 00:00:00 2001 From: "http://svario.it/gioele" Date: Wed, 13 Aug 2014 06:40:12 +0000 Subject: Added a comment --- ...ent_4_f334a85d6dd6c4971f0609ae0831766a._comment | 23 ++++++++++++++++++++++ 1 file changed, 23 insertions(+) create mode 100644 doc/bugs/whereis_does_not_work_in_direct_mode/comment_4_f334a85d6dd6c4971f0609ae0831766a._comment (limited to 'doc') 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 + +"""]] -- cgit v1.2.3 From 1ea8af3294873a682439a84291d8f6e2ec80b1ef Mon Sep 17 00:00:00 2001 From: zardoz Date: Wed, 13 Aug 2014 08:43:19 +0000 Subject: --- ..._if_WORM_keys_do_not_encode_relative_paths.mdwn | 23 ++++++++++++++++++++++ 1 file changed, 23 insertions(+) create mode 100644 doc/bugs/Possible_data-loss_if_WORM_keys_do_not_encode_relative_paths.mdwn (limited to 'doc') 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. + -- cgit v1.2.3