Warum wurde die Option ohne Berücksichtigung der Groß-/Kleinschreibung in ext4 benötigt?

Das Dateisystem ohne Berücksichtigung der Groß- und Kleinschreibung ermöglicht es uns, wichtige Engpässe für Anwendungen zu beheben, die von anderen Betriebssystemen portiert werden

erreicht mein Herz nicht und ich kann nicht verstehen, wie der Normalisierungs- und Casefolding-Prozess es uns ermöglicht, unseren Plattenspeicher zu optimieren.

Wine, Samba und Android haben Dateisystem-Semantik ohne Berücksichtigung der Groß-/Kleinschreibung bereitzustellen. Wenn das zugrunde liegende Dateisystem zwischen Groß- und Kleinschreibung unterscheidet, schlagen Wine et al. muss jedes Verzeichnis scannen, um zu beweisen, dass es keine Übereinstimmungen ohne Berücksichtigung der Groß-/Kleinschreibung gibt (z. B. wenn nach /foo/bar/readme.txt gesucht wird fehlschlägt, müssen Sie eine vollständige Verzeichnisauflistung und einen Groß-/Kleinschreibungsvergleich aller Dateien in foo/bar/* durchführen und alle Verzeichnisse in foo/* , und /* ).

Dabei gibt es einige Probleme:

• Bei tief verschachtelten Pfaden (die Hunderte von FS-Aufrufen generieren können) oder Verzeichnissen mit Zehntausenden von Dateien (d. h. Speichern inkrementeller Sicherungen über SMB) kann es sehr langsam werden.
• Diese Überprüfungen führen Rennbedingungen ein.
• Es ist grundlegend ungesund:wenn beide readme.txt und README.txt existieren, aber eine Anwendung fragt nach README.TXT , welche Datei zurückgegeben wird, ist undefiniert.

Android ging so weit, Groß- und Kleinschreibung mit FUSE/wrapfs und dann dem im Kernel enthaltenen SDCardFS zu emulieren. Allerdings hat SDCardFS alles schneller gemacht, indem es den Prozess in den Kenel Space verlagert†. Es musste immer noch das Dateisystem durchlaufen (und war daher IO-gebunden), führte Race-Bedingungen ein und war im Grunde ungesund. Aus diesem Grund finanzierte Google† die Entwicklung einer nativen verzeichnisspezifischen Groß-/Kleinschreibung in F2FS und hat SDCardFS seitdem als veraltet markiert.

In der Vergangenheit gab es mehrere Versuche, Suchen ohne Berücksichtigung der Groß-/Kleinschreibung über VFS zu ermöglichen. Der letzte Versuch im Jahr 2018 ermöglichte das Mounten einer Groß-/Kleinschreibung des Dateisystems. Ted Tso erwähnte speziell die Probleme mit Wrapfs für das Hinzufügen dieser Funktionalität, da es zumindest schneller und (glaube ich) frei von Race-Conditions wäre. Es war jedoch immer noch nicht stichhaltig (Anforderung von README.TXT könnte readme.txt zurückgeben oder README.txt ). Dies wurde zugunsten des einfachen Hinzufügens von Unterstützung für die Groß-/Kleinschreibung pro Verzeichnis abgelehnt und wird es wahrscheinlich nie in VFS schaffen††.

Darüber hinaus erwarten Benutzer Groß- und Kleinschreibung, daher muss jedes verbraucherorientierte Betriebssystem dies bieten. Unix konnte es nicht nativ unterstützen, da Unicode nicht existierte und Strings nur Bytes waren. Es gibt viele berechtigte Kritikpunkte darüber, wie Case-Folding in der Vergangenheit gehandhabt wurde, aber Unicode bietet eine unveränderliche Case-Fold-Funktion, die für alle außer einem einzigen Gebietsschema funktioniert (Türkisch, und selbst dann sind es nur zwei Codepunkte). Und der Dateisystem-B-Baum ist der einzig sinnvolle Ort, um dieses Verhalten zu implementieren.

†AFAICT
††Ich habe Krisman, dem Autor sowohl der VFS-basierten Suche ohne Berücksichtigung der Groß-/Kleinschreibung als auch der verzeichnisunabhängigen Unterstützung für EXT4 und F2FS, eine E-Mail geschickt.

Andere Betriebssysteme haben ein Dateisystem, bei dem die Groß-/Kleinschreibung nicht beachtet wird.

Als Beispiel:MacOS erlaubt Groß-/Kleinschreibung (als Standard) oder Groß-/Kleinschreibung. Adobe Photoshop und Adobe Lightroom funktionieren nicht gut mit Dateisystemen, bei denen die Groß-/Kleinschreibung beachtet wird. Das bedeutet, dass es innerhalb von Adobe-Programmen wahrscheinlich fest codierte Pfade gibt, die auf unterschiedliche Weise geschrieben sind (vielleicht „Dokumente“ und „Dokumente“ in den verschiedenen Bibliotheken, oder nur manchmal einige Filter angewendet werden (z Pfad der Daten). Niemand hat sich darum gekümmert, weil es einfach funktioniert.

Wenn Sie also jetzt ein Programm portieren möchten, das für ein gängiges proprietäres Betriebssystem unserer Epoche erstellt wurde, sollten Sie entweder alle Pfade korrigieren, damit Sie immer eine konsistente Verwendung von Dateinamen haben, oder Sie bevorzugen ein Dateisystem, das diese behandelt für dich.

Adobe konnte dies für MacOS nicht tun, also erwarten Sie, dass die Dinge für andere Anbieter viel schwieriger (und kostspieliger) sind. Siehe https://helpx.adobe.com/creative-suite/kb/error-case-sensitive-drives-supported.html