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
|
In a v6 repository, `git annex get` of a particular file re-downloaded it
each time it was run. `git annex whereis` said the content was locally
present. But, `git annex fsck` of the file said the content was
missing, and removed it from the location log.
The file was locked, and the repository was on ext4.
Reported by gleachkr on IRC. Don't have enough information to reproduce
the problem yet. --[[Joey]]
> My initial analysis is that this must be a problem with
> `Annex.Content.inAnnex`. Note that checks the cached inode for the
> content and if it finds a mismatch, it behaves as if the content is not
> present. That would be consistent with the problem as reported.
>
> When I init a v6 repository and add some locked files, no inode cache is
> recorded, which makes sense as they're locked.
>
> Hypothesis: A cached inode for the key got into the keys database,
> despite the file being locked, and that is messing up inAnnex.
>
> Should inAnnex even be checking the inode cache for locked content?
> This seems unncessary, and note that it's done for v4 mode as well as v6.
>
> How could a cached inode for a locked file leak in? Perhaps the file
> was earlier unlocked. Or perhaps another, unlocked file, had the same
> content. I tried both these scenarios, and was able to get a cached
> inode to be listed for a file, but in my tests at least, it also cached
> the inode of the locked file, and I did not replicate the problem.
>
> --[[Joey]]
## more information needed
If gleachkr comes back to IRC, it would be good to find out:
* Was this file previously unlocked? `git log` on the file would probably
tell, unless it was briefly unlocked in between commits.
* Run `git annex info` on the file to see what its key is.
Then, run `sqlite3 .git/annex/keys/db` and .dump and see
what is recorded for that key, in both the "content" and "associated"
tables.
|
