(db)fix: file modification detection failing in some edge cases (#2221)
One example of an edge case: - If a file has LF line endings, - and is situated in a repository where .editorconfig asks for CRLF, (Such repositories exist, for example <https://github.com/obsidianmd/obsidian-docs/>.) - and editorconfig-mode is enabled, org-roam-db--file-hash would then return different results depending on whether the file path is passed to it or not. While this is a contrived edge case, there may be other cases like this where the data from insert-file-contents-literally and the data from find-file-noselect makes secure-hash return different values. This commit removes the branch in org-roam-db--file-hash to compute the hash based on buffer content, instead making it always require a file path. (This commit also allows org-roam-db-insert-file to take an optional HASH argument, allowing it to avoid recalculating the hash.) Since now we always compute the hash with the file on disk, the special case for encrypted files is no longer needed. This should have no impact on whether db is synchronized. The only case when db--file-hash uses the "calculate in current buffer" path is in db-insert-file; the only use of db-insert-file is in db-update-file, which already calls db--file-hash with the file path, and does not rely on the value from the current buffer.master
parent
bbac208fda
commit
171a8db32f
1 changed files with 11 additions and 17 deletions
Loading…
Reference in new issue