Dateiname

Dateinamen auf einer Bildschirmkonsole unter Windows

Ein Dateiname identifiziert eine Datei in einem Dateisystem auf einem Datenträger oder bei einer Datenübertragung. Meist wird eine Datei zusätzlich durch einen Verzeichnisnamen charakterisiert, sodass ein vollständiger Pfadname entsteht. Erst diese Kombination zu einem vollständigen Pfadnamen ist in der Regel eindeutig. Pro Verzeichnis (Ordner) ist eine identische Benennung von zwei Dateien nicht möglich – hierbei können Dateinamen vom System normalisiert werden, sodass etwa eine veränderte Groß- und Kleinschreibung keinen Unterschied macht (keine case sensitivity). Die optionale Dateinamenserweiterung ist Teil des Dateinamens.

Eigenschaften

Ein Dateiname kann – abhängig vom jeweiligen Betriebssystem oder Dateisystem – aus mehreren Teilen bestehen. Die einzelnen Teile sind durch bestimmte Zeichen, die in der Regel nicht Teil des vergebenen Namens sind, getrennt. Ein solches Zeichen ist etwa der Punkt, ., der gefolgt von einer Dateinamenserweiterung, hintangestellt, den Typ einer Datei anzeigt; die Liste von Dateinamenserweiterungen verschafft einen Überblick.

Einige Betriebssysteme machen die Behandlung der Dateien allein von der jeweiligen Dateinamenserweiterung abhängig. Andere Betriebssysteme erkennen den Dateityp anhand des Inhalts – beispielsweise anhand einer sogenannten magischen Zahl, mit deren Hilfe sich ein bestimmter Dateityp relativ zuverlässig bestimmen lässt, oder mittels im zur Datei zugehörigen alternativen Datenstrom gespeicherten Daten, etwa zum Dateityp und zum erstellenden Programm. Doch auch auf Systemen, die nicht von einer Dateinamenserweiterung den Dateityp ableiten, werden Dateinamen damit versehen – u. a. da es den Datenaustausch vereinfacht.

Die maximale Länge eines Dateinamens wird sowohl durch das Betriebssystem als auch durch das Dateisystem des Datenträgers begrenzt. So können etwa auf einer CD-ROM bei Verwendung des Joliet-Dateisystems maximal 64 Zeichen genutzt werden. Eine indirekte Begrenzung kann zudem durch eine maximale Länge von Pfadnamen im Betriebssystem entstehen.

Ob beim Dateinamen zwischen Groß- und Kleinbuchstaben unterschieden wird liegt gleichermaßen am verwendeten Betriebssystem und am jeweiligen Dateisystem. Vor allem historische Dateisysteme wurden oft nicht case-sensitive entworfen, das heißt, sie speichern den Dateinamen z. B. generell in Großbuchstaben ab. Die meisten aktuellen Dateisysteme sind jedoch in jedem Fall case-preserving, das heißt, sie halten den Dateinamen in der bei der Erstellung oder Umbenennung benutzten Schreibweise mit Groß- und Kleinbuchstaben vor – das verwendete Betriebssystem oder die jeweilige Programmierschnittstelle (englisch Application Programming Interface, kurz API) können dann sowohl case-insensitive als auch case-sensitive ausgelegt sein.

Dateisysteme

Implementierung

Dateisysteme haben bestimmte interne Strukturen, die meist der des Referenzsystems entsprechen, für das das Dateisystem entwickelt wurde. So besitzt ein Dateisystem meist keine Rechteverwaltung, wenn das Betriebssystem diese ebenfalls nicht kennt. Ein Beispiel dafür ist das Dateisystem FAT von PC DOS bzw. MS-DOS: da DOS selbst kein Mehrbenutzersystem ist, speichert es auch keine Zugriffsrechte für Dateien und Verzeichnisse. Ebenso verhält es sich mit Erstellungs- und Zugriffszeiten von Dateien, die in der systemüblichen Weise entweder als Lokalzeit oder als Universalzeit abgespeichert werden, oder bei der Konvention von Groß- und Kleinschreibung.

Groß- und Kleinschreibung

Die Unterscheidung zwischen Groß- und Kleinbuchstaben wird im Englischen als „case sensitivity“ bezeichnet. Bei der Verwendung von Dateinamen macht es einen großen Unterscheid, ob ein System Dateinamen case-sensitive – mit strikter Unterscheidung – oder nicht-case-sensitive bzw. case-insensitive – ohne Unterscheidung – verarbeitet. Bei case-sensitiven Systemen referenziert Dateiname (mit groß geschriebenem Anfangsbuchstaben) nicht dieselbe Datei wie dateiname (alles in Kleinbuchstaben) oder DATEINAME (alles in Großbuchstaben). Für den Anwender auf einem solchen System ist es essentiell sich an die Schreibweise in der Verzeichnisliste zu halten, denn nur wenn eine Datei mit dem Namen Dateiname auch wirklich existiert, kann sie auch geöffnet und verarbeitet werden. Existiert hingegen nur eine Datei mit demselben Namen in Kleinbuchstaben, dateiname, so gibt das System zurecht einen Fehler aus, dass die Datei mit dem Namen Dateiname nicht existiert.

Historisch gesehen war UNIX, entwickelt Ende der 1960er und Anfang der 1970er Jahre, ein case-sensitives System, also mit strikter Unterscheidung zwischen Groß- und Kleinschreibung.

Anders war es bei den aufkommenden Personal Computern Ende der 1970er und Anfang der 1980er mit den Betriebssystemen CP/M und DOS auf IBM PCs und kompatiblen Computern sowie mit Mac OS auf der Apple-Macintosh-Plattform: diese sind traditionell case-insensitive. Öffnet ein Anwender oder eine Anwendung auf einem solchen System eine Datei namens Dateiname, so wird stattdessen dateiname (in Kleinschreibung) geöffnet, wenn die Datei bereits mit kleingeschriebenem aber sonst gleichem Dateinamen vorhanden ist. Umgekehrt verwehrt das System aber auch die Erstellung einer Datei mit dem Namen DATEINAME (und jeder anderen Schreibweise in Groß- und Kleinbuchstaben), da sich der Dateiname in jedem Fall durch zusätzliche Merkmale unterscheiden muss.

Für ein Computersystem bedeutet case insensitivity, dass es zusätzlichen Aufwand betreiben muss, da es Dateinamen bei jeder Anfrage in alle möglichen Groß- und Kleinschreibungen umformen muss, bis eine Datei dieses Namens gefunden wird. Eine Fehlermeldung, die Datei sei nicht vorhanden (bzw., bei einem Namenskonflikt: die Datei sei bereits vorhanden), kann ein solches System erst dann ausgeben, wenn es alle Möglichkeiten durchprobiert hat.

Ob ein System prinzipiell case-insensitive Dateinamen nutzt oder nicht hat auch Auswirkungen auf das verwendete (für das und mit dem Betriebssystem entwickelte) Dateisystem, denn wenn das Betriebssystem und dessen API grundsätzlich keine Unterscheidung macht, muss es diese auch nicht speichern. Umgekehrt ist es für case-sensitive Systeme jedoch absolut notwendig, die genaue Schreibweise im Dateisystem zu erhalten. Aktuelle Dateisysteme sind jedoch zumindest case-preserving ausgelegt und erhalten die Schreibweise – damit ist es in den allermeisten Fällen ohne Probleme möglich auch System-fremde Dateisysteme mit System-üblichen Dateinamenskonventionen zu verwenden.

Interoperabilität

Das Dateisystem FAT (in den Varianten FAT12, FAT16 und FAT32) ist auf fast allen Betriebssystemen implementiert. Weil das Dateisystem aber bestimmte Annahmen bezüglich des zugrunde liegenden Systems macht – und Dateinamen nur in Großbuchstaben speichert, werden diese z. B. auf unixoiden Betriebssystemen vom Dateisystemtreiber standardmäßig in Kleinbuchstaben umgewandelt. Mit der VFAT-Erweiterung wird diese Umwandlung nur dann vollzogen, wenn der Dateiname in der 8.3-Konvention und in Großbuchstaben im FAT vorliegt. Andere Erweiterungen für FAT, wie UMSDOS, implementieren eigenständig eine solche Umwandlung, wenn die Datei nicht auf Unix gespeichert wurde und im UMSDOS-Format vorgehalten wird. Da Unix/Linux allerdings zwischen Groß- und Kleinbuchstaben unterscheidet, wird eine Datei nur in der umgewandelten oder in der im VFAT gespeicherten Schreibweise erkannt.

Ein Beispiel: Unter Windows (mit VFAT, also ab Windows 95) wird eine Datei mit dem Namen Dateiname.Ext gespeichert. Diese wird unter Windows, weil Windows „case-insensitive“ ist, auch in einer anderen Schreibweise erkannt, beispielsweise in der Eingabeaufforderung mit del dateiname.ext gelöscht. Unter Linux wird genau diese Datei jedoch nur in der genauen Schreibweise Dateiname.Ext erkannt. Will man beispielsweise die Datei mit less anzeigen und vertippt sich z. B. bei der Dateinamenserweiterung: less Dateiname.ext, so gibt Linux die Fehlermeldung aus, dass die Datei nicht existiert.

Es kommt also nicht nur auf das Dateisystem an, sondern auch auf das Betriebssystem, und wie es mit den im Dateisystem vorgehaltenen Informationen (Dateiname, Rechte, Datum) umgeht. Unter Umständen kann z. B. ein Dateisystemtreiber zwar auf die Eigenheiten des Dateisystems eingehen, die Betriebssystemumgebung verhindert dies jedoch. Ein Beispiel ist der Umgang einer Unix-Shell mit Wildcards. Unter Linux ist im Dateisystemtreiber für AFFS die „case-insensitivity“ eingebaut, nicht jedoch in der Shell. Ist auf einem Amiga-„Fast File System“ beispielsweise der Dateiname DateiName (mit teilweise Großbuchstaben) gespeichert, so kann dieser in der Unix-Shell mit rm dateiname (alles in Kleinbuchstaben) gelöscht werden, weil der Dateisystemtreiber die Umwandlung vollzieht. Gibt man jedoch rm dat* ein, wird DateiName nicht gelöscht, weil die Unix-Shell die Suche nach dem Dateinamen vollzieht – da diese „case-sensitive“ ist, wird keine Übereinstimmung gefunden, weil die Shell strikt zwischen Groß- und Kleinbuchstaben unterscheidet.^[6]

Auch die Zugriffsrechte und Besitzer von Dateien können auf unterschiedlichen Betriebssystemen entweder übernommen oder vollkommen ignoriert werden. Der FUSE-Dateisystemtreiber NTFS-3G beispielsweise unterstützt die Zugriffsbeschränkung, wenn die betreffende Windows-Benutzer-SID zuvor einem Unix-Benutzer zugeordnet wurde (englisch user mapping).^[7]

Betriebssysteme

Unix

Unix- und Unix-ähnliche Betriebssysteme wie zum Beispiel Solaris oder Linux betrachten Dateinamen als Ganzes. Eine Datei kann mehrere Namen haben und sich in mehreren Verzeichnissen befinden („hard links“ oder „bind mounts“). Alle Zeichen außer dem Schrägstrich / und dem Nullzeichen sind erlaubt. Frühe Versionen hatten 1 bis 14 Zeichen lange Dateinamen. Die BSD-Varianten führten bis zu 255 Zeichen lange Namen ein.

Ein relativer Dateipfad kann aus mehreren Segmenten bestehen und beginnt mit einem Segment. Jedes Segment unterliegt den Regeln des Dateinamens, kann also 14 bzw. 255 Zeichen lang sein. Die Segmente der Dateipfade werden durch das Zeichen / getrennt. Das letzte Segment kennzeichnet die eigentliche Datei. Die vorhergehenden Segmente sind entweder Verzeichnisnamen oder symbolische Verweise (englisch „symbolic links“) auf Verzeichnisnamen. Ein relativer Dateipfad geht vom aktuellen Arbeitsverzeichnis aus, das jeder Prozess individuell setzen kann. Ein absoluter Dateipfad beginnt hingegen bereits mit / und ist unabhängig vom aktuellen Arbeitsverzeichnis. Er geht vom Wurzelverzeichnis aus. Über das Wurzelverzeichnis sind alle Dateien eines Systems erreichbar.

Beim Zugriff wird zwischen Groß- und Kleinschreibung unterschieden. Anders als z. B. unter DOS ist unter Unix auf der Shell (entspricht unter DOS der Eingabeaufforderung) bei ausführbaren Dateien (Kommandos, Programme, Skripte) immer der vollständige Dateiname inklusive Erweiterung anzugeben.

Beispiele:

# vi /home/user/Dokumente/brief.txt

# cd /home/user/Dokumente
# /usr/local/bin/texteditor brief.txt

Der Dateiname . (Punkt) bezeichnet das aktuelle Arbeitsverzeichnis. Der Name .. verweist auf das übergeordnete Verzeichnis.

# ./mein-shell-script.sh
# ../../usr/local/bin/programm-oder-shellscript

Auch das Leerzeichen, der Zeilentrenner oder die sogenannten Wildcards * und ? können Teil eines Pfadnamens sein. Solche Zeichen bringen allerdings manchmal später Probleme mit sich, da zum Beispiel schlecht programmierte Skripte damit nicht umgehen können. Weiterhin kann es Probleme mit Dateinamen geben, die Zeichen enthalten, die im aktuell verwendeten Zeichensatz eines Programms nicht vorkommen (zum Beispiel japanische Zeichen auf einem amerikanisch eingerichteten System). Die nicht darstellbaren Zeichen werden dann oft als Fragezeichen oder kleine Kästchen angezeigt, was den Zugriff auf die Daten sehr schwierig macht. Diese Dateien können dann oft nur bearbeitet werden, nachdem sie auf einer niedrigen Dateisystem-Abstraktionsebene umbenannt wurden (zum Beispiel durch Angabe der sogenannten inode statt des Dateinamens mit ls -i und find . -inum […] -exec mv {} […] \;).

Ein Unix-System verwendet keine speziellen Erweiterungen, wie .EXE oder .CMD. Es hat sich allerdings eingebürgert, Dateien eines bestimmten Types, wie in anderen Betriebssystemen, auch mit einem Punkt und einer entsprechenden Erweiterung zu versehen, um die Übersichtlichkeit zu erhöhen. Beispielsweise wird die Endung .c für C-Quellprogramme verwendet. Ausführbare Dateien, etwa Programme, erhalten keine Endung, sondern das Dateireicht x für execute (dt. ausführen). Shellskripte verwenden teilweise die Endung .sh, meist jedoch wie Programme keine Dateinamenserweiterung, um auf der Unix-Shell einfacher aufgerufen werden zu können. Dateitypen können ansonsten mit dem einfachen Programm file ermittelt werden, unabhängig von einer eventuell vorhandenen Erweiterung.

Dateien oder Verzeichnisse, deren Namen mit einem Punkt beginnen, werden üblicherweise als „versteckte“ Dateien behandelt und nur angezeigt, wenn der Benutzer dies explizit angibt (zum Beispiel mit ls -a).

Ähnliches gilt für Verzeichnispfade.

CP/M, DOS, Windows bis Version 3.11

Dateinamen bestehen unter CP/M sowie den verschiedenen PC-kompatiblen DOS-Versionen inkl. Windows bis zur Version 3.11 (Windows 3.x) aus einem maximal acht Zeichen umfassenden eigentlichen „Namen“ sowie optional einem Punkt und einer maximal drei Zeichen umfassenden „Erweiterung“ (englisch extension), die auch den Typ der betreffenden Datei angibt (siehe 8.3). Erweiterungen werden oft von Programmen vergeben bzw. für Programme reserviert, zum Beispiel die Erweiterung .TXT für Textdateien. Auch die Betriebssysteme selbst verwenden spezielle Erweiterungen wie beispielsweise .BAT für Skriptdateien, .SYS für Treiberdateien oder .EXE und .COM für ausführbare Dateien.

Ein Dateiname inklusive Erweiterung darf aus folgenden Zeichen bestehen:^[8]

1. Buchstaben, A–Z (Kleinbuchstaben werden automatisch in Großbuchstaben umgewandelt)
2. Ziffern, 0–9
3. Die Sonderzeichen ` ' { } ( ) % & - @ # $ ~ ! _ ^

Die folgenden Zeichen sind dabei, da sie in den genannten Systemen syntaktische Funktionen erfüllen, in Dateinamen und Erweiterungen nicht erlaubt:^[8]

1. ASCII-Steuerzeichen
2. Leerzeichen
3. Die Sonderzeichen ? * < > . , \ + : = / " ; [ ] |

Außerdem sind einige Worte reserviert und dürfen nicht als Dateiname benutzt werden, da sie als Gerätenamen verwendet werden:

AUX, CON, NUL, PRN
COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9
LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, LPT9

Dadurch kann man unter klassischem DOS zum Beispiel die folgenden Dateinamen, die unter anderen Betriebssystemen zulässig sein können, nicht benutzen: aux.c, q"uote"s.txt, NUL.txt.

Verzeichnisnamen werden unter den genannten Betriebssystemen wie normale Dateinamen gehandhabt. Sie haben üblicherweise keine Erweiterung, können jedoch mit einer solchen versehen werden. Diese hat dann in der Regel, anders als beim Namen von sonstigen Dateien, keine Funktion. Jede Datei und jedes Verzeichnis befindet sich auf einem Laufwerk, welches durch einen Buchstaben und einen Doppelpunkt gekennzeichnet wird. Ein vollständiger Name besteht aus dem Laufwerk, optional einem oder mehreren Verzeichnisnamen und dem eigentlichen Dateinamen. Die genannten Bestandteile werden durch das Verzeichnistrennsymbol \ voneinander getrennt.

A:\MSDOS.SYS
C:\DOKUMENT\BRIEF.TXT

Da nur acht Zeichen zur Verfügung stehen, werden die Bezeichnungen oft verstümmelt. Die Namen . und .. sind wie unter Unix für das aktuelle Verzeichnis und das übergeordnete Verzeichnis reserviert.

Beim Zugriff wird nicht zwischen Groß- und Kleinschreibung unterschieden.

Windows ab Version 95

Unter Windows, sowohl der Windows-9x- als auch der Windows-NT-Linie, besteht ein Dateiname aus dem Namen, einem Punkt und einer Erweiterung, die den Dateityp festlegt. Es können auch mehrere Punkte in einem Dateinamen angegeben werden, der letzte Punkt dient dann zur Trennung von Name und Erweiterung.

Länge von Dateiname und Pfad

Normalerweise ist die Pfadlänge unter Windows auf 260 Zeichen beschränkt, d. h. drei Zeichen für die Laufwerksangabe, 256 Zeichen für den Pfad innerhalb des Laufwerks und ein nicht sichtbares String-Terminierungszeichen. Längere Pfade bis zu 32.767 Zeichen, wie sie von NTFS unterstützt werden, sind mittels UNC (Uniform Naming Convention) möglich, d. h. \\?\ muss vorangestellt werden.^[9]

Zur Wahrung der Kompatibilität mit alten MS-DOS-Programmen kann der Dateiname auch in der 8.3-Notation angegeben werden, wenn dies in Windows nicht deaktiviert wurde. Dabei wird der Dateiname eindeutig mit acht Zeichen für den Namen, einem Punkt und bis zu drei Zeichen für die Dateierweiterung dargestellt, welche in jedem Verzeichnis neu generiert werden. Wenn Dateien ihren langen Dateinamen verloren haben, sie also nur diesen spezifischen Kurznamen haben, kann es zu Konflikten mit schon existierenden Dateien mit langem Dateinamen kommen, deren Dateiname auf denselben Namen verkürzt wurde, auch wenn sie vorher in einem anderen Verzeichnis problemlos koexistierten. (→8.3)

Problematische und unzulässige Zeichen oder Namen

In Dateinamen und Erweiterungen sind, wie schon unter DOS und Windows bis Version 3.11, folgende Zeichen nicht erlaubt:

    < > ? " : | \ / *

Ebenfalls unzulässig sind folgende, wie schon zuvor als Gerätenamen reservierte Dateinamen:

CON, PRN, AUX, NUL
COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9
LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, LPT9

Dadurch kann man auch unter den neueren Windows-Versionen zum Beispiel folgende Dateinamen, die unter anderen Betriebssystemen erlaubt sein können, nicht benutzen: aux.c, q"uote"s.txt, NUL.txt.

Problematisch sind außerdem Dateinamen, die das eigentlich erlaubte &-Zeichen enthalten, das von der DOS-Umgebung unter Windows jedoch als Trennzeichen einzeiliger Befehlsketten verwendet wird, so dass alles auf ein &-Zeichen Folgende als eine weitere DOS-Befehlszeile interpretiert wird. In der Konsequenz gibt die Windows-Eingabeaufforderung daher in diesem Fall eine Fehlermeldung aus, dass sie einen Befehl nicht finden oder ausführen konnte, dessen Name der Rest des eingegebenen Dateinamens nach dem &-Zeichen ist, ganz zu schweigen davon, dass die fragliche Datei selbst natürlich auch nicht geöffnet oder bearbeitet werden konnte.

Zusätzlich sind auch Dateinamen problematisch, die am Ende ein Leerzeichen haben. Diese kann man unter Windows nicht anlegen; werden sie unter anderen Betriebssystemen erstellt, kann man auf sie unter Windows nicht zugreifen, da Windows die Leerzeichen am Ende einfach abschneidet. Autoren von Schadprogrammen haben dies bereits ausgenutzt, da dadurch Anti-Virenprogramme nur durch besondere Maßnahmen auf solche Dateien zugreifen können.

Ansonsten können alle im Unicode-Standard definierten Zeichen benutzt werden, wobei in der Praxis ältere Applikationen oft mit Zeichen Schwierigkeiten haben, deren Code nicht im Windows-1252-Zeichensatz enthalten ist.

VMS

Unter VMS (Virtual Memory System) besteht ein Dateiname aus dem Namen, einem Punkt, einer Erweiterung, einem Semikolon und einer Versionsnummer. Die Versionsnummer wird bei jeder Neuanlage einer gleichnamigen Datei (mit Erweiterung) automatisch um Eins erhöht. Dadurch kann man mehrere Versionen (Anzahl ist einstellbar, maximal 32.767) derselben Datei gleichzeitig halten. Die folgenden Angaben gelten für ODS-2 (englisch on disk structure):

Dateinamen können maximal 39 Zeichen lang sein, wobei nur bestimmte Zeichen (Buchstaben, Ziffern, Unterstrich, Dollarzeichen) erlaubt sind. Es wird nicht zwischen Groß- und Kleinschreibung unterschieden. Die Erweiterung kann ebenfalls 39 Byte lang sein, wird durch einen Punkt getrennt und ist nicht Teil des Dateinamens. Außer bei Verzeichnissen, wo die Erweiterung immer .DIR lautet, hat sie aber keine Bedeutung für die mögliche Verwendung der Datei (es gibt aber Standards, die bei einigen Dateitypen üblicherweise eingehalten werden).

Die Gesamt-Pfadlänge (also Disk, Verzeichnisbaum, Dateiname, Erweiterung und Version) darf 255 Bytes nicht überschreiten.

Internet

World Wide Web

Die Übertragung von Dateien im World Wide Web ist durch den HTTP-Standard geregelt. Enthält ein Dateiname Zeichen außerhalb der ASCII-Buchstaben und -Ziffern, so werden diese in der URL in einer %-Darstellung codiert mit einem Prozentzeichen, gefolgt von einem Zwei-Zeichen-Code in hexadezimaler Form, etwa haust%FCr.html statt haustür.html. Um den Codewert ermitteln zu können, ist die Kenntnis der Zeichencodierung (zum Beispiel UTF-8 oder ISO 8859-1) des Dateinamens nötig.

Dateidownload

Der FTP-Standard sieht nur ASCII-Zeichen als zwingend unterstützt vor. Oft wird ein Dateidownload allerdings auch unter Benutzung von HTTP durchgeführt.

E-Mail

Die Übertragung von Dateianhängen (und damit auch die dort zulässigen Dateinamen) ist in den Standards SMTP und MIME geregelt.

Weblinks

Wiktionary: Dateiname – Bedeutungserklärungen, Wortherkunft, Synonyme, Übersetzungen

Einzelnachweise

1. ↑ Craig A. Finseth: The Craft of Text Editing: Emacs for the Modern World. Springer Science & Business Media, 2012, S. 181 (englisch, eingeschränkte Vorschau in der Google-Buchsuche): “…PDP-10s running ITS (the Incompatible Timesharing System) … that system's file name syntax.  DEV;DIR:PRTONE PRTTWO  Each part can be up to 6 characters long…” 
2. ↑ “The Xerox Alto Computer” (englisch) aus BYTE, Ausgabe 9/1981, Seiten 58–68
3. ↑ Thorsten Leemhuis: Kernel-Log: Linux 5.2. In: Heise online. 28. Juni 2019. S. 2: Ext4-Dateisystem kann jetzt Groß- und Kleinschreibung ignorieren. Abgerufen am 25. November 2022.; Zitat: „Entwickler haben dieses „Casefold Feature“-Feature entwickelt, um es bei Android einzusetzen – bislang nutzt das Mobilbetriebssystem einen eher uneleganten Hack in Form einer „Wrapfs“ genannten Zwischenschicht, um Case Insensitivity mit Ext4 zu erzielen.“.
4. ↑ Abschnitt Maximum Path Length Limitation MSDN, Naming Files, Paths, and Namespaces.
5. ↑ Richard Russon, Yuval Fledel: NTFS Documentation.
6. ↑ affs-Dokumentation für den Linux-Kernel (englisch), Abschnitt „Bugs, Restrictions, Caveats“; abgerufen am 12. Juni 2016.
7. ↑ Tuxser – NTFS-3G User Mapping (englisch); abgerufen am 12. Juni 2016.
8. ↑ ^{a b} Computing Center Newsletter: MICRO digest: MS-DOS Filenames and Common Extensions. (englisch). The University of Michigan, Ann Arbor 1986, Vol. 16, No. 2, 8
9. ↑ Naming Files, Paths, and Namespaces. In: MSDN. Microsoft, abgerufen am 13. September 2011 (englisch).