summaryrefslogtreecommitdiff
path: root/doc/bugs/copy_unused_and_unused_not_agreeing/comment_9_6abca5f4927e09089cdc5f0bd27b798f._comment
blob: 25edfd5edf6729218355325acf7b02111ffd4a2a (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
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="209.250.56.146"
 subject="analysis"
 date="2014-03-06T21:37:15Z"
 content="""
[[!format haskell \"\"\"
        {- In indirect mode, look for the key. In direct mode,
         - the inode cache file is only present when a key's content
         - is present, so can be used as a surrogate if the content
         - is not located in the annex directory. -}
\"\"\"]]

Seems that is wrong.

I think that comment was based on removeAnnex calling removeInodeCache, which it does do.
And that is, afaik, the only point in git-annex where content files are removed from the annex.

However, in direct mode, removeAnnex is not the only way to delete a key's content -- the user can simply delete the file!
(Or a disk error could put it in lost+found, or whatever.)

That leaves the inode cache file present. unused will then behave as you describe. Also, uninit throws an ugly warning message
due to getKeysPresent giving it bad data. The only other caller of getKeysPresent is info, which will also operate on bad data and so generate slightly wrong stats.

I'm leaning toward making getKeysPresent do a full check of the cache and map, checking that the work tree still contains a key's content. This will make it somewhat slower (by 2 file reads and a stat() per key). So it would make sense to make a variant that only lists keys with content present in .git/annex/objects/. That could be used by `unused`, since by definition unused keys cannot have their content located in the work tree, so must have it in the object directory. uninit could also use it, since it's only interested in cleaning out .git/annex/objects. Only `info` will be slowed down.
"""]]