Вопрос

После открытия файла в emacs (через ssh-туннелированную файловую систему, подключенную к sshfs) Я получаю символические ссылки, подобные этой:

.#jobid.php -> ddh@localhost.localdomain.31678:1260471633

Мы определили, что это файлы блокировки emacs.

Файловая система sshfs смонтирована с помощью follow_symlinks и transform_symlinks, но, похоже, она отказывается возвращать текст ссылки через readlink, поэтому emacs не удаляет их.

Это было полезно?

Решение

Если вы ищете документацию, Emacs обращается к этим файлам как блокировки файлов.

Вместо использования sshfs/FUSE вы можете получить доступ к удаленным файлам непосредственно из Emacs:

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

Emacs не создает блокировки файлов при редактировании удаленных файлов таким образом — для получения дополнительной информации о редактировании удаленных файлов найдите «TRAMP».(К сожалению, я думаю, что Emacs не может определить, что ваша точка монтирования FUSE поддерживается удаленной файловой системой или что создание блокировок файлов на ней проблематично.)

Другие советы

Эти символические ссылки используются emacs для предотвращения изменения одного и того же файла несколькими экземплярами emacs.Символическая ссылка обычно исчезает, когда вы сохраняете файл, но похоже, что предохранитель-sshfs мешает этому процессу, поскольку целью символической ссылки не является настоящий файл (это не должно быть так, но sshfs этого ожидает).

К сожалению, я не знаю, как отключить эту функцию или заставить emacs хранить эти символические ссылки в другом каталоге (я использую emacs нечасто и ничего не нашел в руководстве), поэтому вам, возможно, придется просто периодически удалять Боюсь, их вручную.

Тот самый follow_symlinks опция заставляет символические ссылки в удаленной системе отображаться как реальные файлы.Это полезно, когда символическая ссылка ссылается на цель на удаленном хосте вне каталога, который монтируется через sshfs, но это нарушает предположения Emacs, потому что, когда Emacs создает символическую ссылку, он ожидает, что этот же путь позже будет выглядеть как символическая ссылка.

Однако вы должны быть в состоянии заставить все символические ссылки на удаленном хосте работать корректно, сохраняя при этом вид символических ссылок, используя transform_symlinks вариант (и не follow_symlinks) и всегда монтируйте корневой каталог удаленной системы (а не просто ваш домашний каталог или что-то в этом роде).Это должно позволить emacs злоупотреблять символическими ссылками как файлами блокировки, сохраняя при этом доступность удаленных объектов символьных ссылок.

Эти символические ссылки создаются Emacs, когда буфер посещает файл, и они не позволяют двум экземплярам Emacs редактировать один и тот же файл (как упоминалось в других ответах).Emacs называет это «обнаружением конфликтов».

К сожалению, единственный способ предотвратить такое поведение в GNU emacs — во время компиляции.В исходной документации описано, как это сделать, изменив заголовок.

Это связано с тем, что функции lock-buffer и unlock-buffer являются примитивами и вызываются другими примитивами для создания этих символических ссылок.В более старых версиях Emacs их можно переопределить или дефальсифицировать в elisp, но примитив не заметит этого изменения.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top