摘要：Org Roam 的数据库似乎有些任性，每次同步都要重新来过，全量更新。探究其原因，竟然是因为配置路径使用了软链接(symbolic link)。但别担心，我们有办法应对。最直接的解决方式是优化 org-roam-db-sync 的逻辑，但在此之前，我们可以通过设置真实路径或使用 file-truename 函数来暂时避免问题。示例如下：
(setq org-directory (file-truename "~/Notebooks/")
org-roam-directory (file-truename "~/Notebooks/RoamNotes/")
)
故事背景：
每次启动 Emacs 或同步数据库，我都得面对那句“Processing modified files…”，它总是不紧不慢地在屏幕上跑。即便在性能强劲的 M2 Mac 上，也得费上那么几秒钟。这个过程原本应该是增量更新，但它却把所有文件都重新搞了一遍。这让 Org 认为所有文件都是新修改过的。
就算一字未动，同步操作也会像全新处理一样。虽然这不会影响使用，但像鞋里的小石子一样，虽小却足以搅扰人心。
昨日实在忍无可忍，我翻开了那段神秘的代码。
代码的逻辑本身设计得相当周到。首先，它会在 Roam 路径下获取所有文件，然后计算每个文件的 hash 值，并与数据库中的 hash 值进行比对，以此来识别哪些文件发生了变更，需要处理。但问题出在 org-roam-list-files 函数上，它获取的是 symbolic link 的路径，而 org-roam-db--get-current-files 函数获取的则是数据库中存储的绝对路径，这就导致了比对时的不匹配：
(let* ((gc-cons-threshold org-roam-db-gc-threshold)
(org-agenda-files nil)
(org-roam-files (org-roam-list-files))
(current-files (org-roam-db--get-current-files))
(modified-files nil))
(dolist (file org-roam-files)
(let ((contents-hash (org-roam-db--file-hash file)))
(unless (string= (gethash file current-files)
contents-hash)
(push file modified-files)))
(remhash file current-files))
解决方案已经在眼前，就看我们何时着手实施了。在此之前，上述临时方案可保你心情舒畅，免受等待之苦。
我发现即使在广阔的网络世界，有关这一问题的信息也寥寥无几。这加强了我分享解决方案的决心，希望我的发现能够帮助到那些面临相似困境的同伴。
在这段技术探索的旅途中，我有几点心得想与大家共勉：
-
动手实践比仅仅头脑风暴要来得真切。 使用
debug-on-entry来追踪 Emacs 的运行情况，就像是为代码的逻辑流动打上了标签，让我能一步步揭开问题的面纱。 -
个性化配置往往伴随着独特的挑战。 我的 Org Roam 配置使用了 symbolic link，这种小众做法使我不得不面对额外的挑战。这次经历提醒我，对于这些特殊的设置，我必须保持警觉，准备好解决可能出现的问题。
如果我要给这段经历再加点料，或许是这样：
-
社区的力量是无穷的。 尽管我自己解决了问题，但我相信将这些发现分享给社区，一定会激发更多的讨论和解决方案，从而帮助更多使用 Org Roam 的用户。毕竟，很多头脑拼在一起，总能碰撞出火花。
-
记录与反思是成长的阶梯。 这次的问题解决过程，再次提醒我记录自己的发现和思考过程的重要性。每一次回顾，都可能发现新的知识点或更好的处理方法。
希望我的这些小发现和心得，能为大家带来一些启发，也期待与你们在 Org Roam 的道路上相遇。
