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]]