Lock-Files und Multi-Edit

Was Lock-Files sind und wann sie entstehen

Eine Lock-Datei in Emacs ist kein echtes File, sondern ein symbolischer Link mit einem speziell formatierten Ziel-String. Der Dateiname folgt dem Muster .#originaldateiname — aus notes.md wird also .#notes.md, aus foo.go wird .#foo.go. Das Symlink-Ziel hat die Form:

user@host.pid:bootzeitstempel

Konkret zum Beispiel michael@macbook.74321:1715900000 — das reicht Emacs, um zu unterscheiden, ob der Lock von der eigenen Sitzung stammt, von einer anderen Sitzung desselben Users, von einem anderen User oder gar von einem Reboot her noch übrig ist.

Wann der Lock entsteht — und wann er verschwindet

Wichtig für das Verständnis: Emacs legt den Lock nicht beim Öffnen einer Datei an, sondern beim ersten Modifizieren des Buffers. Reines Lesen erzeugt also nie eine Lock-Datei. Sobald du speicherst oder die Änderungen mit revert-buffer verwirfst, wird der Lock automatisch entfernt.

Das lässt sich leicht selbst beobachten:

1. Datei mit C-x C-f öffnen.
2. Im Terminal ls -la im Verzeichnis aufrufen — kein .#dateiname zu sehen.
3. In Emacs ein beliebiges Zeichen tippen.
4. ls -la erneut — jetzt taucht der Symlink .#dateiname auf.
5. C-x C-s zum Speichern — der Symlink verschwindet wieder.

Wer die Datei-Operationen rund um diese Schritte vertiefen will, findet sie im Vorgänger-Artikel Dateien öffnen und speichern.

Wozu Lock-Files gut sind

Das klassische Szenario: zwei Emacs-Instanzen — sei es zwei Sitzungen desselben Users oder zwei User auf einem gemeinsam genutzten Server — öffnen dieselbe Datei. Ohne Lock-Mechanismus würde derjenige, der zuletzt speichert, die Änderungen des anderen still überschreiben. Emacs nennt diesen Schutz „interlock".

Sobald die zweite Sitzung mit dem Tippen beginnt, sieht sie den vorhandenen Lock und stellt im Minibuffer einen Prompt:

foo.go locked by michael@macbook (pid 74321): (s, q, p, ?)

Die drei Antworten haben sehr unterschiedliche Konsequenzen:

s (steal) ist die kollisionsbereite Variante: die andere Sitzung bekommt beim nächsten Speicherversuch ihrerseits den „File has changed since visited or saved"-Prompt (siehe Dateien öffnen und speichern) und muss dann entscheiden. p (proceed) verzichtet auf den Lock-Steal — du editierst parallel, der Konflikt entsteht erst beim Speichern. q ist die sichere Variante: erst klären, warum ein Lock da ist, bevor irgendetwas geändert wird.

Wer das Format überhaupt versteht

Die Lock-Konvention ist eine Emacs-Konvention. GNU Emacs liest und schreibt sie, einige weitere Werkzeuge respektieren sie (manche Shell-Tools und Notebook-Server) — aber VS Code, JetBrains-IDEs, Sublime, Nano, Vim und die meisten anderen Editoren wissen nichts von .#name-Symlinks. Sie ignorieren die Lock-Datei vollständig und überschreiben die Datei nach Belieben. Wer regelmäßig zwischen Emacs und einem anderen Editor wechselt, kann sich auf den Schutz also nicht verlassen — Versionskontrolle (siehe Magit) bleibt das robustere Sicherheitsnetz.

Wann Lock-Files stören

So sinnvoll der Mechanismus für klassische Multi-User-Setups ist — in modernen Solo-Workflows produziert er regelmäßig Probleme. Die vier häufigsten:

Cloud-Sync-Ordner

Dropbox, iCloud Drive, OneDrive, Google Drive und Syncthing watchen ihre überwachten Verzeichnisse permanent. Sobald Emacs einen .#dateiname-Symlink anlegt, registriert der Sync-Client den neuen „File". Drei typische Folgen:

• Sync-Konflikt-Dateien: der Sync legt auf einem zweiten Gerät seine Konflikt-Variante an (Dateiname (conflict copy).ext), obwohl gar kein echter Konflikt vorliegt.
• Fehlinterpretation: manche Provider behandeln Symlinks nicht als solche, sondern dereferenzieren sie — und kopieren dann nichts, weil das Symlink-Ziel (user@host.pid:...) als Pfad keinen Sinn ergibt.
• Symlinks werden gelöscht: andere Provider verweigern Symlinks ganz und räumen sie still auf, was Emacs später als „Lock wurde gestohlen" interpretieren kann.

Container-Mounts

Docker-Volumes, devcontainer-Bind-Mounts und einige Netzwerk-Dateisysteme unterstützen Symlinks nicht oder nur eingeschränkt. Wenn Emacs den Lock anlegen will und das fehlschlägt, kommt ein Fehler beim Schreiben — der Bearbeitungsfluss bricht ab, obwohl die eigentliche Datei problemlos beschreibbar wäre.

Datei-Watcher in Build-Toolchains

Webpack, Vite, esbuild, Sass-Watcher und viele Linter überwachen Quell-Verzeichnisse rekursiv. Jeder Lock-Symlink triggert ein Watch-Event — was im besten Fall nur Rauschen im Watcher-Log produziert, im schlechtesten unnötige Rebuilds oder Reloads im Browser.

Versionskontrolle

Lock-Files gehören niemals in ein Repository. Die Ergänzung im .gitignore ist Pflicht:

# Emacs lock files (interlock symlinks)
.#*
# Backup files
*~
# Auto-save files
\#*\#

Die drei Zeilen decken die wichtigsten Emacs-Artefakte ab: Locks (.#*), Backups (*~) und Auto-Saves (#*#). Details zu Backups und Auto-Saves im Artikel Auto-Save und Backups.

Lock-Files deaktivieren

Die Erstellung von Lock-Files steuert eine einzige Variable: create-lockfiles. Auf nil gesetzt, legt Emacs gar keine Locks mehr an:

;; Keine .#name-Lock-Symlinks mehr anlegen
(setq create-lockfiles nil)

Wo dieser Code hingehört

Die Zeile gehört in deine init.el (üblicher Pfad: ~/.emacs.d/init.el oder seit Emacs 27 ~/.config/emacs/init.el). Ab dem nächsten Emacs-Start ist die Lock-Erstellung deaktiviert. Hintergrund zu Konfigurations-Reihenfolge, use-package und early-init.el: Konfiguration mit init.el und early-init.el.

Empfehlung nach Setup

Granularer: nur in problematischen Verzeichnissen aus

Wer den globalen Default behalten und Locks nur in einem bestimmten Pfad abschalten will, nutzt eine .dir-locals.el im Projektroot:

;; Locks nur in diesem Verzeichnis (und darunter) deaktivieren
((nil . ((create-lockfiles . nil))))

Diese Datei legt man in den Wurzel-Pfad des betroffenen Projekts (z. B. den Cloud-Sync-Ordner). Emacs liest sie automatisch beim Öffnen jeder Datei darunter und übernimmt die buffer-lokale Variable.

Alternative: Locks woandershin umleiten

Wenn Locks erwünscht sind, aber nicht neben der Datei liegen sollen, hilft lock-file-name-transforms — ein Regex-Mapping, das die Lock-Pfade in ein zentrales Verzeichnis (z. B. ~/.emacs.d/locks/) umleitet. Das ist der saubere Mittelweg für Cloud-Sync-Szenarien, in denen man den Schutz nicht ganz aufgeben will. Die Konfiguration ist analog zu backup-directory-alist aufgebaut und wird im Artikel Auto-Save und Backups im Detail behandelt.

revert-buffer: Buffer aus Datei neu laden

Der Gegenspieler des Locks ist der Reload: wenn eine Datei sich außerhalb von Emacs verändert hat (Git-Pull, Linter-Reformat, anderer Editor, Build-Tool), willst du den Buffer-Inhalt durch den frischen Datei-Inhalt ersetzen. Das macht revert-buffer. Zwei Wege:

• Tastenkombi (ab Emacs 28): C-x x g
• Funktion direkt: M-x revert-buffer RET

Die Binding C-x x g ruft technisch revert-buffer-quick auf — eine modernere Variante, die ohne Rückfrage revertet, solange der Buffer nicht modifiziert ist. Hat der Buffer ungespeicherte Änderungen, fragt sie sicherheitshalber nach. In älteren Emacs-Versionen (vor 28) gibt es die Tastenkombi nicht — dort ist M-x revert-buffer RET der einzige Weg.

Was passiert mit modifizierten Buffern

Der wichtigste Punkt: ein Revert überschreibt deine ungespeicherten Änderungen mit dem Datei-Inhalt. Es ist kein Merge. Bei modifizierten Buffern erscheint die Sicherheitsfrage:

Buffer has been modified; revert anyway? (yes or no)

Wer yes antwortet, ist seine im Buffer getippten Änderungen los — die ehrliche Rettung dafür heißt C-/ (undo): Emacs legt das Revert als einen einzelnen Undo-Schritt ab, der die ursprünglichen Buffer-Inhalte zurückbringt. Diese Undo-Garantie macht revert-buffer weniger gefährlich, als es klingt — solange man im selben Buffer bleibt.

Major-Mode wird neu angewendet

Beim Revert wendet Emacs den passenden Major-Mode neu an, basierend auf dem Datei-Inhalt und der Dateiendung. Das ist nützlich, wenn sich das Format der Datei geändert hat (etwa weil ein Generator sie umstrukturiert hat) — und gelegentlich nervig, wenn man buffer-lokale Mode-Einstellungen verloren hat.

Verwandt: revert-buffer-with-fine-grain

M-x revert-buffer-with-fine-grain RET ist die schonende Variante: sie versucht, Marker, Text-Properties und Overlays über den Revert hinweg zu erhalten. Bei großen Änderungen ist sie langsamer als der Standard-Revert, bei kleinen Patches aber spürbar reibungsärmer — etwa wenn ein Linter nur einzelne Zeilen umformatiert hat und Bookmarks im Buffer erhalten bleiben sollen.

global-auto-revert-mode: automatisches Nachladen

Wer den Reload nicht jedes Mal manuell auslösen will, schaltet den globalen Auto-Revert ein. Dann beobachtet Emacs alle Datei-Buffer im Hintergrund und lädt sie nach, sobald die Datei auf Disk sich verändert hat — vorausgesetzt, der Buffer hat keine ungespeicherten Änderungen.

;; Buffer automatisch nachladen, wenn die Datei sich extern geaendert hat
(global-auto-revert-mode 1)

;; Auch Nicht-Datei-Buffer wie Dired und Magit-Status mitziehen
(setq global-auto-revert-non-file-buffers t)

;; Keine Meldung pro Reload — sonst rauscht die Echo-Area
(setq auto-revert-verbose nil)

Wo dieser Code hingehört

Wie alle dauerhaften Einstellungen kommt der Block in deine init.el (siehe Konfiguration mit init.el und early-init.el). Nach dem nächsten Emacs-Start ist Auto-Revert systemweit aktiv.

Was Emacs unter der Haube macht

Auto-Revert nutzt nach Möglichkeit Datei-Benachrichtigungen des Betriebssystems (kqueue auf macOS und BSDs, inotify auf Linux, ReadDirectoryChangesW auf Windows) — Veränderungen werden also nahezu in Echtzeit erkannt, ohne dass Emacs pollen muss. Steht keine OS-Notification zur Verfügung, fällt der Modus auf Polling zurück; das Intervall steuert auto-revert-interval (Default 5 Sekunden).

Die Sicherheits-Garantie

Wichtig und oft missverstanden: Auto-Revert überschreibt nie einen modifizierten Buffer. Sobald du das erste Zeichen tippst, ist der Buffer für den Mechanismus tabu — bis du selbst speicherst oder manuell revertest. Auch gelöschte oder umbenannte Dateien werden nicht automatisch behandelt; der Buffer bleibt mit seinem letzten bekannten Inhalt stehen.

Wann sich der globale Modus lohnt

global-auto-revert-non-file-buffers t ist der Schalter, der Dired und einige andere Buffer-Typen mit revertbarem Inhalt mitnimmt. Ohne dieses Flag bleibt Auto-Revert auf reine Datei-Buffer beschränkt.

Bei Tramp: aus Performance-Gründen per Default aus

Über Tramp geöffnete Remote-Dateien werden vom Auto-Revert per Default nicht überwacht — das Polling über SSH wäre teuer und würde die Verbindung dauerhaft beschäftigen. Wer es trotzdem will, setzt:

;; Auto-Revert auch fuer Remote-Dateien (Vorsicht: kostet Bandbreite)
(setq auto-revert-remote-files t)

In der Praxis lohnt sich das nur für sehr aktive Remote-Workflows mit schneller Verbindung.

auto-revert-tail-mode: tail -f im Editor

Eine Spezial-Variante des Auto-Revert ist auto-revert-tail-mode. Statt den ganzen Buffer beim Reload neu zu lesen, hängt der Modus nur den neuen Datei-Ende-Abschnitt an den existierenden Buffer-Inhalt an — Funktionsweise und Performance entsprechen dem Unix-Klassiker tail -f.

• Funktion direkt: M-x auto-revert-tail-mode RET

Der Modus aktiviert sich pro Buffer und ist gedacht für Dateien, die rein additiv wachsen — also Logs. Anwendungsfälle, in denen er die Terminal-Variante schlägt:

• Suche im Log: C-s mit Isearch durch die laufenden Einträge.
• Bookmarks an markanten Stellen — bei wiederkehrenden Fehlern ein Sprungziel mit C-x r m setzen.
• Filter-Buffer via occur oder keep-lines/flush-lines, um nur relevante Zeilen rauszuziehen.
• Mehrere Logs gleichzeitig in nebeneinanderliegenden Fenstern, ohne mehrere Terminal-Tabs.

Praktischer Hinweis: wenn ein Log rotiert (also auf Disk durch eine neue, leere Datei ersetzt wird), folgt auto-revert-tail-mode der Rotation nicht automatisch — der Buffer zeigt dann weiter den alten Inhalt. In dem Fall hilft ein einmaliges M-x revert-buffer RET oder ein erneutes Öffnen der Datei.

Weiterführende Ressourcen

Externe Quellen

• GNU Emacs Manual — Interlocking — offizielle Beschreibung des Lock-Mechanismus, create-lockfiles und lock-file-name-transforms.
• GNU Emacs Manual — Reverting a Buffer — revert-buffer, revert-buffer-quick und revert-buffer-with-fine-grain.
• GNU Emacs Manual — Auto Revert — globaler und buffer-lokaler Auto-Revert-Modus, auto-revert-tail-mode, Optionen rund um Polling und Notifications.

Verwandte Artikel

• Dateien öffnen und speichern
• Auto-Save und Backups
• Encoding und Zeilenenden
• Dired — Datei-Verwaltung im Buffer
• Magit
• Tramp-Grundlagen
• Konfiguration mit init.el und early-init.el