diff options
| -rw-r--r-- | doc/todo/use_inode_cache_in_unlocked_files.mdwn | 23 |
1 files changed, 23 insertions, 0 deletions
diff --git a/doc/todo/use_inode_cache_in_unlocked_files.mdwn b/doc/todo/use_inode_cache_in_unlocked_files.mdwn new file mode 100644 index 000000000..adf2bc3dd --- /dev/null +++ b/doc/todo/use_inode_cache_in_unlocked_files.mdwn @@ -0,0 +1,23 @@ +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.. |