Zeilenenden, Kodierungen und Pfade: was schiefgeht, wenn eine Datei zwischen Betriebssystemen wechselt

Worum es geht

Vier voneinander unabhängige Kompatibilitätsfallen, die sich alle gleich äussern: Die Datei sieht lokal korrekt aus und funktioniert anderswo nicht.

• Zeilenenden: Windows-Textwerkzeuge schreiben traditionell CRLF (\r\n), Unix-artige Werkzeuge nur LF (\n). Ein Skript mit Shebang-Zeile, das mit CRLF gespeichert wurde, scheitert unter Linux mit einem Fehler der Art "interpreter not found", weil das abschliessende \r zum Teil des Interpreterpfads wird.
• Kodierungen und Byte-Order-Marks: In Windows PowerShell 5.1 schreiben Out-File und > UTF-16LE mit BOM, Set-Content schreibt die veraltete ANSI-Codepage, und -Encoding UTF8 bedeutet UTF-8 mit BOM; PowerShell 7 verwendet standardmässig UTF-8 ohne BOM (utf8NoBOM). Eine Datei, die mit der einen Version geschrieben und von einem strikten UTF-8-Parser gelesen wird, kann drei unerwartete führende Bytes enthalten oder gänzlich unlesbar sein.
• EBCDIC: Systeme der IBM-Mainframe-Familie (z/OS und historisch weitere IBM-Plattformen) können Text in EBCDIC-Codepages wie cp037 darstellen, die Byte für Byte inkompatibel mit ASCII/UTF-8 sind. Wird eine Datei ohne expliziten Konvertierungsschritt übertragen (FTP im Binär- statt Textmodus oder ohne explizites iconv), kommt auf der Gegenseite nur unlesbarer Datensalat an.
• Gross-/Kleinschreibung und Pfadlänge: ext4 unterscheidet standardmässig Gross- und Kleinschreibung (ab Linux 5.2 lassen sich einzelne Verzeichnisse davon ausnehmen, allerdings nur auf einem Dateisystem, das mit dem Feature casefold erstellt oder nachträglich angepasst wurde, und nur für leere Verzeichnisse, die mit chattr +F markiert sind); APFS unter macOS wird standardmässig in einer Variante ohne Unterscheidung der Gross-/Kleinschreibung ausgeliefert, das Festplattendienstprogramm bietet zusätzlich ein separates Format mit Unterscheidung an; NTFS ist im normalen Gebrauch nicht case-sensitiv, bewahrt die Schreibweise aber (ab Windows 10 1803 lassen sich einzelne Verzeichnisse mit fsutil file setCaseSensitiveInfo als case-sensitiv markieren). Windows begrenzte Pfade historisch auf MAX_PATH (260 Zeichen), sofern eine Anwendung die Unterstützung langer Pfade nicht ausdrücklich aktiviert.

Warum es wichtig ist

Zwei Dateien, die sich nur in den Zeilenenden oder einem BOM unterscheiden, können einen Prüfsummenvergleich oder die Shebang-Auflösung scheitern lassen oder der ersten Zeile, die ein Programm liest, stillschweigend ein überzähliges Zeichen voranstellen. Abweichungen bei der Gross-/Kleinschreibung führen dazu, dass etwas auf dem Mac funktioniert, im Linux-Container aber fehlschlägt, wenn sich zwei Dateien nur in der Schreibweise unterscheiden und das nicht case-sensitive Dateisystem sie stillschweigend als eine behandelt hat. Pfadlängenlimits machen aus einer tief verschachtelten Build-Ausgabe einen Fehler, der nur unter Windows auftritt und sich unter Linux oder macOS nie reproduzieren lässt.

So wird es angewendet

• Zeilenenden an der Repository-Grenze explizit normalisieren (z. B. mit .gitattributes), statt sich auf den Standardwert eines Editors zu verlassen.
• Beim Schreiben von Text aus PowerShell, der anderswo weiterverarbeitet wird, in PowerShell 7 explizit -Encoding utf8NoBOM angeben. Windows PowerShell 5.1 kennt diesen Wert nicht und weist ihn zurück; dort BOM-loses UTF-8 mit [System.IO.File]::WriteAllText(PATH, TEXT, [System.Text.UTF8Encoding]::new($false)) und einem absoluten PATH schreiben.
• Vor jeder Dateiübertragung im Mainframe-Umfeld den Übertragungsmodus (Text oder binär) prüfen und, falls EBCDIC beteiligt ist, die Konvertierung explizit durchführen und verifizieren, dass ein bekanntes Textmuster die Hin- und Rückkonvertierung unverändert übersteht.
• Dateinamen, die sich nur in der Gross-/Kleinschreibung unterscheiden, auf jedem Dateisystem testen, das nicht direkt unter eigener Kontrolle steht; nicht davon ausgehen, dass das Zielsystem dem Standard der eigenen Entwicklungsmaschine entspricht.

Stolpersteine

• Einen "file not found"-Fehler, der durch abweichende Gross-/Kleinschreibung entsteht, auf einem nicht case-sensitiven Mac beheben, nur damit er wieder auftaucht, sobald derselbe Code in der CI auf einem case-sensitiven Linux läuft.
• Annehmen, dass die Unterstützung langer Pfade unter Windows überall greift, sobald sie an einer Stelle aktiviert wurde; viele Anwendungen und ältere APIs erzwingen MAX_PATH unabhängig von der systemweiten Einstellung weiterhin.