Verzeichnis Ordnung

Was kommt in welches Datei-Verzeichnis?

Dieses Frage beantworten viele Programme mit festgelegten (hard-gecodeten) Verzeichnispfaden. Und wenn dann in einer Quelldatei ein c:\programme\ oder /usr/local/bin drinnen steht … tja dann fängt die Hölle Feuer.


Ein ehemaliger Kollege meinte einmal:

Diese bibliothekarisch sortierten Verzeichnisstrukturen sind nicht mehr zeitgemäß und sollten durch etwas intuitiveres ersetzt werden.

Nur leider ist genau das bis heute nicht massentauglich geschehen.

Ein beachtlicher Anteil an Software wird wegen falschen Dateipfaden regelmäßig von Ausfällen geplagt und muss dann durch neuere Versionen mit ebenso hässlichen Workarounds ersetzt werden.

Das Problem sind fehlende Standards oder die fehlende Durchsetzung eben solcher. Auch wenn dieser Zustand in den letzten 15 Jahren sichtlich besser wurde, verschwunden ist er leider noch nicht.

Windows

Windows hatte ursprünglich aus der DOS-Zeit die Idee der absoluten Freiheit übernommen. Man durfte alles überall hinspeichern, nur einige wenige Verzeichnisse wie C:\DOS und C:\Windows sollten verschont bleiben. Doch auch das passierte nicht und so ward die DLL-Hölle geboren, wo jeder App-Installer die DLLs seiner Software im System Unterverzeichnis von Windows ablegte und damit die Versionen anderer Softwareprodukte überschrieb. Das Resultat waren die lustigsten Formen von Abstürzen and anderem Fehlverhalten.

Mit Windows 95 wurde dann c:\Program Files eingeführt, welches dann auch noch in alle Sprachen übersetzt wurde. Und so hieß der Ordner im deutschsprachigen Raum c:\Programme und wir lernten dann recht flott, dass auch viele kommerziellen Profi-Tools mit der Installation nach c:\Program Files offenbar etwas falsch machten.

Ebenso schlimm waren private Daten, die in Win9X unter c:\Eigene Dateien oder C:\Windows\Profiles\name landen konnten, je nach Systemeinstellung. Windows NT verabschiedete sich dann auch noch von C:\Windows und setzte anfangs c:\WinNT bzw. c:\wtsrv ein, womit Benutzerdaten eben dort im Unterverzeichnis Profiles\username zu finden sein sollten.

Mit Windows 2000 und XP wurde C:\Windows wieder gültig und ein c:\Documents and Settings eingeführt, was im Deutschen wieder C:\Dokumente und Einstellungen hieß.
Erst Windows Vista und 7 legten C:\Users in allen Sprachen als Primärziel fest, erstellten aber übersetzte Dateisystem-Links wie c:\Benutzer.

All das sollten die Programmierer nicht im entferntesten kümmern, denn diese Pfade sollten nie in Programmen enthalten sein, sondern sollten per Aufruf wie etwa über SHGetSpecialFolderPathW abgefragt werden.

Doch weil genau das nicht immer geschah erlebte Windows hier ein Chaos. Angefangen bei z.B.: Microsoft’s Visual Basic 4, das nur in c:\VB installiert werden sollte, verunreinigten auch viele andere Tools das Dateisystem mit solchen Eigenmächtigkeiten.

Linux, BSD

Theoretisch hatten es Linux und generell Unix Systeme richtig gemacht. Mit der Root-Dateisystem Konvention für Unterverzeichnisse existiert quasi ein Standard, der alle unterschiedlichen Implementierungen vereint.
Man findet also unter /etc immer alle globalen Konfigurationsdateien, /dev enthält nur Gerätetreiber und deren Datenströme und /home ist die Basis für die Unterverzeichnisse pro registriertem Benutzer. /var für logs und lokale Hilfsdateien und /tmp für Temporäres dürfen ebenso wenig fehlen wie /bin und /sbin für Systemtools und /usr als Host für alle weiteren Programme.
Ab /media und /mnt wird es schon knifflig, welche Mountpoints man darunter findet.

Doch leider haben unterhalb dieser Ebene die Distributionen ihre Meinungsfreiheit zu sehr ausgenutzt.
Und so findet man die gleichen Softwareprodukte mal unter /usr/bin und mal unter /usr/local/bin, womit ein paar Scripts ihre Portierbarkeit verlieren und Probleme bereiten, wenn sie Dateien falsch duplizieren oder nicht finden.

Nachdem POSIX und Linux keine APIs für die Pfade vorsehen, wählte man Umgebungsvariablen wie $HOME um “leichter” zum richtigen Verzeichnis gelangen zu können. Doch wenn Programme exec falsch nutzen und kein Environment oder eine manipuliertes Environment weitervererben, verhalten sich Bibliotheken ob der unkorrekten Variablen falsch.
Und schon landen Dateien im Arbeitsverzeichnis oder können wegen fehlender Rechte gar nicht geschrieben werden.

Auf /etc ist wiederum unter FreeBSD kein Verlass, denn nicht-elementare Systemkonfigurationen (z.B. Zusatztdienste wie sudo) speichern ihre Einstellungen dann manchmal in /usr/local/etc … und man wundert sich, warum die Einstellungen in /etc einfach nicht greifen wollen.

/tmp ist heute meist nur noch ein Link auf /var/tmp oder ein anderes nutzerspezifisches Verzeichnis. Doch leider beginnen Distributionen nun damit dieses alte Standardverzeichnis erst gar nicht mehr anzulegen. Und da die Variable $TMP auch nicht immer vorhanden ist, überlässt man es Drittbibliotheken, den richtigen Pfad zu finden.

Dass das nicht immer so gut klappt, merkt man erst nach vielen Stunden Debug-Logs entschlüsseln, wenn man ein Open Source Projekt heruntergeladen und kompiliert hat und dieses einfach nicht starten möchte.

Es sind also nicht nur die distributionsspezifischen Scripts sondern auch Binärprogramme, die ohne spezielle Anpassungen ihr Lauffähigkeit einbüßen.

Fazit

Programme hätten eigentlich das Potential - einmal geschrieben - ewig zu leben. Dass es ausgerechnet bescheuerte Dateisystem Pfade sind, die sich von OS zu OS-Version so ändern und dann Funktionsstörungen auftreten, ist sehr ärgerlich.

Doch eben dafür sollten die OS-Hersteller stabile Schnittstellen etablieren, die die Wirrungen der Zeit überdauern und den Programmen sagen, wohin sie ihre Daten schreiben dürfen. Natürlich bringt es auch nichts, diese Schnittstellen ständig imkompatibel abzuändern, was wieder zum Nutzen von hart kodierten Pfaden in den Programmen führt.

Im GATE Projekt versuche ich diese Wirrungen durch Funktionen aufzulösen, doch genau hier merkt man leider sehr intensiv, wie unterschiedlich sogar die Versionen der gleichen Plattform sind. Auch in den Quellen anderer Programme findet sich eine Vielzahl solcher Sonderfall-Lösungen.

Was uns leider fehlt ist EIN von allen akzeptierter Standard !!


Wenn sich eine triviale Erkenntnis mit Dummheit in der Interpretation paart, dann gibt es in der Regel Kollateralschäden in der Anwendung.
frei zitiert nach A. Van der Bellen
... also dann paaren wir mal eine komplexe Erkenntnis mit Klugheit in der Interpretation!