Why does sshfs cause these Emacs artifacts?

Question

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.

Answer 1

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:

C-x C-f /ssh:host.name:/path/to/file RET

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.)

Answer 2

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.

Answer 3

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.

Answer 4

The follow_symlinks option 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_symlinks option (and not follow_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.