Unter Windows 11 gibt es nach wie vor eine Regel, die aus den frühesten Tagen der Personal-Computer-Software stammt. Sie verhindert, dass bestimmte Dateinamen - und sogar deren Varianten mit Endungen oder hochgestellten Ziffern - angelegt werden können. Die Konsequenz ist nicht nur ein historisches Relikt, sondern ein praktisches Hindernis für die plattformübergreifende Softwareentwicklung.

Historischer Ursprung der reservierten Gerätekürzel

Die bekannten Namen CON, PRN, AUX, NUL sowie die Serien COM1-COM9 und LPT1-LPT9 gehen nicht auf Microsoft zurück, sondern auf das Betriebssystem CP/M von Gary Kildall (1974). CP/M definierte logische Ein-/Ausgabegeräte - zum Beispiel CON (Console) und PRN (Printer). 1980 adaptierte Tim Paterson diese Gerätebezeichnungen für 86-DOS, das später zu MS-DOS 1.0 (August 1981) wurde. Microsoft übernahm damit die "magischen Dateinamen", um die Portierung alter CP/M-Programme zu erleichtern.

  • 1974: Einführung von CP/M v1 mit Gerätenamen CON, PRN, AUX, NUL.
  • 1980: 86-DOS übernimmt die Namen für die IBM-PC-Kompatibilität.
  • 1981: MS-DOS 1.0 veröffentlicht die selben reservierten Namen.

Wie Windows 11 die alten DOS-Regeln umsetzt

Die Win32-API von Windows blockiert heute den gesamten Namensstamm, unabhängig von einer Dateiendung. Das bedeutet, dass nicht nur reine Namen wie CON verboten sind, sondern auch Varianten wie con.txt, aux.json oder nul.tar.gz von der API abgelehnt werden. Die offizielle Win32-Dokumentation listet 22 Basis-Reservierungsnamen (CON, PRN, AUX, NUL, COM1-COM9, LPT1-LPT9) und sechs erweiterte Varianten mit hochgestellten Ziffern (COM¹-COM³, LPT¹-LPT³).

  • 22 Basis-Gerätenamen (ohne COM0/LPT0).
  • 6 Superscript-Varianten (¹, ², ³) laut ISO/IEC 8859-1.
  • Blockierung gilt für alle Dateiendungen.

Win32-API-Einschränkung vs. Dateisystem-Realität (NTFS/ReFS)

Das Dateisystem NTFS oder ReFS verbietet diese Namen nicht. Die Sperre liegt ausschließlich in der Win32-Normalisierungsschicht. Entwickelt man jedoch Low-Level-Zugriffe mit dem NT-Namespace-Präfix \?\, wird die Normalisierung umgangen und die Datei kann physisch angelegt werden. Gleiches gilt für das Windows-Subsystem für Linux (WSL), das direkt auf Kernel-Ebene arbeitet. Solche Dateien erscheinen im Explorer jedoch als unzugängliche "Geisterdateien", die weder geöffnet noch gelöscht werden können.

  • NT-Namespace-Präfix \?\ überspringt die Win32-Pfadnormalisierung.
  • WSL kann reservierte Namen ohne Fehlermeldung anlegen.
  • Explorer und andere Win32-Programme können diese Dateien nicht verwalten.

Praktische Folgen für moderne Entwickler:innen

In Open-Source-Repositories, die unter Linux oder macOS erstellt wurden, tauchen häufig Dateinamen wie aux.c, con.py oder prn.js auf. Bei einem git clone oder git checkout auf Windows 11 liefert die Win32-API den Fehler "invalid path". Die Git-Konfiguration core.protectNTFS (seit 2023) verhindert standardmäßig das Auschecken dieser Namen. Entwickler*innen müssen entweder die Dateien im Remote-Repository umbenennen oder Workarounds wie git sparse-checkout einsetzen.

  • Git-Fehler: "invalid path" beim Checkout von Dateien mit reservierten Namen.
  • Konfiguration core.protectNTFS verhindert das Auschecken unter Windows.
  • Workaround: git sparse-checkout oder Umbenennung auf Linux/macOS.

Risiken beim Umgehen der Sperre

Wer versucht, die Sperre über Tools, WSL oder den NT-Namespace-Präfix zu umgehen, erzeugt Dateien, die von Backup- und Sicherungs-Software häufig nicht erkannt werden. Solche "Geisterdateien" können das Löschen blockieren und zu inkonsistenten Dateisystem-Snapshots führen. Zudem besteht die Gefahr, dass Legacy-Skripte und Systemtreiber, die auf die klassischen Gerätenamen angewiesen sind, durch das Entfernen der Sperre beschädigt werden.

  • Manuelles Erzwingen führt zu nicht löschbaren Dateien.
  • Backup-Tools können scheitern oder Ordner blockieren.
  • Entfernen der Sperre würde Millionen von Legacy-Skripten und Treibern gefährden.

FAQ - häufige Fragen

  • Darf ich eine Datei 'con.txt' oder 'aux.pdf' nennen? Nein. Die Win32-Namenskonvention sperrt den gesamten Namensstamm, unabhängig von der Endung.
  • Warum kann ich unter WSL eine Datei 'aux.txt' anlegen, im Windows Explorer aber nicht? Das NTFS-Dateisystem akzeptiert den Namen; die Blockade befindet sich in der Win32-API, die Explorer verwendet. WSL arbeitet direkt auf Kernel-Ebene und umgeht diese Schicht.
  • Was mache ich, wenn ein Git-Repository wegen 'aux'- oder 'con'-Dateien nicht klont? Optionen: Datei im Remote-Repository umbenennen (Linux/macOS) oder den betroffenen Ordner unter Windows via git sparse-checkout vom Checkout ausschließen.

Zahlen, Daten und Fakten

  • 22 Mindest-Reservierungsnamen in der Win32-Dokumentation (2024, Source S1).
  • 6 Superscript-Varianten (COM¹-COM³, LPT¹-LPT³) (2024, Source S1).
  • Einführungsjahr CP/M v1: 1974 (Source S2).
  • Einführungsjahr MS-DOS 1.0: 1981 (Source S3).

Fazit

Die Sperrung von Gerätenamen wie CON, PRN, AUX, NUL und deren Varianten ist kein bloßes Relikt, sondern ein bewusst erhaltenes Element der Abwärtskompatibilität. Sie hat tiefe historische Wurzeln in CP/M und 86-DOS, wird heute durch die Win32-API durchgesetzt und wirkt sich unmittelbar auf moderne Entwicklungs-Workflows aus - besonders beim plattformübergreifenden Einsatz von Git. Während das Dateisystem NTFS solche Namen technisch zulässt, verhindert die API-Schicht den Zugriff über den Windows-Explorer. Entwickler*innen müssen daher entweder die betroffenen Dateinamen anpassen oder gezielte Umgehungs- und Sparse-Checkout-Strategien einsetzen, ohne dabei die Risiken von Geisterdateien zu ignorieren. Die Entscheidung von Microsoft, die Regel beizubehalten, spiegelt das langfristige Spannungsfeld zwischen hundertjähriger Legacy-Unterstützung und den Anforderungen moderner APIs wider.