33 lines
1.8 KiB
Markdown
33 lines
1.8 KiB
Markdown
When using git annex unlock, followed by git annex add, it currently
|
|
checksums files, even if the file has not changed.
|
|
|
|
Direct mode has a better approach for this: The inode cache can pretty
|
|
reliably detect if a file has been modified. So, `unlock` could note
|
|
a file's inode cache info, and then `add` could check if a file's inode
|
|
cache is unchanged, and rather than re-checksum it, just perform a fast
|
|
`lock`.
|
|
|
|
Question: How would `add` know what key's inode cache to look at? Seems it
|
|
would need to either check the git branch (as direct mode does, but this is
|
|
rather slow and would slow down `add` in the more common case of adding
|
|
lots of new files), or use a yet-unimplemented [[design/caching_database]].
|
|
Or, the inode cache could be stored in a map with the work tree filename,
|
|
but that diverges from how direct mode uses inode caches.
|
|
|
|
Observation: Using the inode cache info to detect changes is not perfect;
|
|
if a file is modified without changing its size or mtime, the inode cache
|
|
won't be able to tell it's changed. This is unlikely, but possible. In
|
|
direct mode, the worst that can happen in this case is probably that a
|
|
modified file doesn't get added and committed. But, using the inode cache
|
|
for unlocked files would result in any such modified versions being thrown
|
|
away when the file is added, which is much more data lossy..
|
|
|
|
> This bug was regarding v5 unlock/lock. In v6 mode, locking a
|
|
> file doesn't need to rechecksum it; the key is pulled out of the
|
|
> associated files database, and the inode cache is used to detect if the
|
|
> unlocked file has been modified and so avoid data loss.
|
|
>
|
|
> So, this is [[done]] but only for v6 mode. I don't think I want to
|
|
> backport it to v5 mode though; it fell out naturally as a consequence of
|
|
> v6 mode, but to support it in v5 mode would be a lot more work.
|
|
> --[[Joey]]
|