omit inode from ContentIdentifier for directory special remote
Directory special remotes with importtree=yes now avoid unncessary overhead when inodes of files have changed, as happens whenever a FAT filesystem gets remounted. A few unusual edge cases of modifications won't be detected and imported. I think they're unusual enough not to be a concern. It would be possible to add a config setting that controls whether to compare inodes too, but does not seem worth bothering the user about currently. I chose to continue to use the InodeCache serialization, just with the inode zeroed. This way, if I later change my mind or make it configurable, can parse it back to an InodeCache and operate on it. The overhead of storing a 0 in the content identifier log seems worth it. There is a one-time cost to this change; all directory special remotes with importtree=yes will re-hash all files once, and will update the content identifier logs with zeroed inodes. This commit was sponsored by Brett Eisenberg on Patreon.
This commit is contained in:
parent
7ccddd4aea
commit
73df633a62
5 changed files with 34 additions and 11 deletions
|
@ -26,3 +26,5 @@ an inode sentinal file and checking it to tell when inodes have changed
|
|||
would need importing to write to the drive. That seems strange, and the
|
||||
drive could even be read-only. May be the directory special remote should
|
||||
just not use inode numbers at all?
|
||||
|
||||
> [[done]] --[[Joey]]
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue