Verzeichnis Ordnung
« | 10 Jan 2021 | »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. Zusatzdienste 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
benutzerspezifisches 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 inkompatibel 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 !!