1 files changed, 23 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.
+