blob: 761ee5b25b36745d47752a6a1c7bbee51f406a51 (
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
|
I'm on an nfs mounted filesystem (some netapp somewhere). This is repeatable, every time.
git init repo; cd repo;
git annex init repo
truncate -s 20M big
git annex add big
git commit -m "annexed file"
cd ..
git clone repo repo_copy
cd repo_copy;
git annex get .
git annex whereis big
#whereis big (2 copies)
# 9310b242-6021-4621-8cef-4548a00907ff -- here
# b3526e4d-38d7-4781-a9c3-436007899f1b -- origin (repo)
#ok
git annex drop big
#git-annex: /nfspath/repo_copy/.git/annex/objects/fM/4k/SHA1-s20971520--9674344c90c2f0646f0b78026e127c9b86e3ad77: removeDirectory: unsatisified constraints (Directory not empty)
#failed
#git-annex: drop: 1 failed
git annex drop big # no error second time, I suspect nfs has caught up by now.
git annex fsck # Doesn't know that the second drop succeeded.
#fsck big (fixing location log)
# ** Based on the location log, big
# ** was expected to be present, but its content is missing.
#failed
#git-annex: fsck: 1 failed
git annex fsck
#fsck big ok
git annex whereis big
#whereis big (1 copy)
# b3526e4d-38d7-4781-a9c3-436007899f1b -- origin (repo)
#ok
I suspect git-annex is just too fast and optimistic for big slow nfs directories.
> git-annex locks files while it is operating on their content
> to avoid race conditions with other git-annex processes.
> Quite likely this problem (which I can reproduce) is due to
> NFS having bad (non-POSIX) locking semantics.
>
> Probably the
> lock is represented on the NFS server as some form of lock file
> next to the file being locked, and so when that file is deleted, with
> the lock still held, the directory, which should then be empty, still
> contains this lock file.
>
> So, this can be worked around by it not failing when the directory
> unexpectedly cannot be removed. I've made that change. [[done]]
> --[[Joey]]
|
