blob: 716c76f6c6f254ed00d89198244fb58b8ac17809 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
|
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.
> [[fixed|done]] --[[Joey]]
|
