为什么 sshfs 会导致这些 Emacs 伪影？
在 emacs 中打开文件（通过 ssh 隧道、sshfs 安装的文件系统）后，我得到如下符号链接：
.#jobid.php -> [email protected]:1260471633
我们已确定这些是 emacs LOCK 文件。
sshfs 文件系统使用 follow_symlinks 和 transform_symlinks 挂载，但它似乎拒绝通过 readlink 返回链接“文本”，因此 emacs 不会删除它们。
After opening a file in emacs (over an ssh tunneled, sshfs mounted file system) I get symbolic links like this:
.#jobid.php -> [email protected]:1260471633
We have determined that these are emacs LOCK files.
The sshfs filessystem is mounted with follow_symlinks and transform_symlinks, but it appears to be refusing to return the link 'text' via readlink so emacs is not removing them.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
如果您正在寻找文档，Emacs 将这些文件称为 文件锁。
您可以直接从 Emacs 访问远程文件，而不是使用 sshfs/FUSE：
以这种方式编辑远程文件时，Emacs 不会创建文件锁 - 搜索“TRAMP”以获取有关编辑远程文件的更多信息。 （不幸的是，我猜 Emacs 无法判断您的 FUSE 挂载点是否由远程文件系统支持，或者在其上创建文件锁是有问题的。）
In case you're looking for documentation, Emacs refers to these files as file locks.
Instead of using sshfs/FUSE, you can access remote files directly from Emacs:
Emacs doesn't create file locks when editing remote files in this manner-- search for "TRAMP" for more info about editing remote files. (Unfortunately, I guess Emacs can't tell that your FUSE mountpoint is backed by a remote filesystem or that creating file locks on it is problematic.)
emacs 使用这些符号链接来防止多个 emacs 实例修改同一文件。当您保存文件时，符号链接通常会消失，但听起来fuse-sshfs正在干扰此过程，因为符号链接的目标不是真正的文件（它并不意味着，但 sshfs 期望如此）。
不幸的是，我不知道如何禁用此功能或强制 emacs 将这些符号链接存储在不同的目录中（我很少使用 emacs，并且在手册中没有找到任何内容），因此您可能必须定期删除恐怕是手动的。
Those symlinks are used by emacs to prevent multiple emacs instances from modifying the same file. The symlink normally goes away when you save the file, but it sounds like fuse-sshfs is interfering with this process since the target of the symlink isn't a real file (it isn't meant to be, but sshfs expects it).
Unfortunately, I don't know of a way to disable this feature or force emacs to store these symlinks in a different directory (I use emacs infrequently and I didn't find anything in the manual), so you may have to just periodically delete them manually I'm afraid.
follow_symlinks 选项强制远程系统上的符号链接显示为实际文件。当符号链接引用远程主机上通过 sshfs 安装的目录之外的目标时，这很有用，但它打破了 Emacs 的假设，因为当 Emacs 创建符号链接时，它期望相同的路径稍后看起来像符号链接。
但是，您应该能够使用
transform_symlinks选项（而不是follow_symlinks）并始终挂载根目录，使远程主机上的所有符号链接正常工作，同时仍然显示为符号链接远程系统的（而不仅仅是您的主目录或其他目录）。这应该允许 emacs 滥用符号链接作为锁定文件，同时仍然使远程符号链接目标可访问。The
follow_symlinksoption forces symlinks on the remote system to appear as actual files. This is useful when the symlink refers to a target on the remote host outside the directory that is mounted via sshfs, but it breaks Emacs's assumptions because when Emacs creates a symlink, it expects that same path to look like a symlink later.However, you should be able to make all symlinks on the remote host work correctly while still appearing as symlinks by using the
transform_symlinksoption (and notfollow_symlinks) and always mounting the root of the remote system (instead of just your home directory or something). This should allow emacs to abuse symlinks as lockfiles while still making remote symlink targets accessible.这些符号链接是在缓冲区访问文件时由 Emacs 创建的，它们会阻止两个 Emacs 实例编辑同一文件（如其他答案中所述）。 Emacs 将此称为“冲突检测”。
不幸的是，在 GNU emacs 中防止这种行为的唯一方法是在编译时。源文档描述了如何通过更改标头来执行此操作。
这是因为锁定缓冲区和解锁缓冲区函数是原语，并且由其他原语调用来创建这些符号链接。在旧版本的 Emacs 中，可以在 elisp 中重新定义或消除别名，但原语不会注意到此更改。
These symlinks are created by Emacs when a buffer is visiting a file, and they prevent two Emacs instances from editing the same file (as mentioned in other answers). Emacs refers to this as "clash detection".
Unfortunately, the only way to prevent this behavior in GNU emacs is at compile time. The source docs describe how to do this by changing a header.
This is because the lock-buffer and unlock-buffer functions are primitives, and are called by other primitives to create these symlinks. In older versions of Emacs, they can be redefined or defaliased in elisp, but a primitive will not notice this change.