summaryrefslogtreecommitdiff
path: root/doc/bugs/WORM_keys_differ_depending_on_working_dir_during_add.mdwn
blob: 9787ad5cc6520c60d9f0c4e1a82b7e49c5217bc9 (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
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
### Please describe the problem.

While the docs say that WORM keys are a function of a files basename,
when doing «git annex add .», the generated keys will actually contain
the relative path (with slashes escaped). Not sure whether this is by
design or a bug in its own right. I suppose that to minimize the chance
of collisions on WORM, having the path within the key is preferable.

A problem about this, however, is that the path in the key is not
stable, but varies with the working dir when doing the «git annex
add». So, when a file is added from one working dir (say, the repo
base), later unlocked, and readded from another working dir (say,
somewhere below the repo base), this will generate a different key
even when the file has not been touched.

Is there a rationale for this variability, or should «add» canonicalize
the encoded paths to the repo root?


### What steps will reproduce the problem?


[[!format sh """

# Init
$ git init /tmp/foo
$ cd /tmp/foo && git annex init

$ mkdir baz
$ touch baz/quux

# Add file with working dir at repo root.
$ git annex add --backend=WORM baz
$ git commit -m "first"

# Key includes relative path.
$ readlink baz/quux
../.git/annex/objects/8x/8V/WORM-s0-m1406981486--baz%quux/WORM-s0-m1406981486--baz%quux

# Unlock and readd with working dir at path below repo root.
$ cd baz
$ git annex unlock quux

$ git annex add quux
$ git com -m "second"

# Relative path is anchored to working dir instead of repo root.
$ readlink quux
../.git/annex/objects/9G/72/WORM-s0-m1406981486--quux/WORM-s0-m1406981486--quux

# End of transcript or log.
"""]]

### What version of git-annex are you using? On what operating system?
Linux 3.15.8

git-annex 5.20140716

> This was a bug. I suspect it got broken a while ago and I didn't noticed
> since I rarely use WORM and when I do it's almost always adding files
> in the current directory. [[fixed|done]] to take the filename only.
> 
> I don't think it's a problem to have the subdirectory path in the
> existing WORM keys, other than the problems you note with this meaning
> a later add of the same file will generate a different key. So I have not
> done anything to try to fix up existing keys. (If this became a problem,
> I could add upgrade code to the WORM backend.)
> --[[Joey]]