Zum Inhalt springen

8.3

aus Wikipedia, der freien Enzyklopädie
Dies ist die aktuelle Version dieser Seite, zuletzt bearbeitet am 17. Juni 2025 um 18:13 Uhr durch imported>Prüm (Einzelnachweise).
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)

8.3, auch 8-Punkt-3-Namen und retronym {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value) für kurze Dateinamen genannt, ist eine häufig verwendete Schreibweise, die die historische Beschränkung von acht Zeichen für den Dateinamen und drei Zeichen für die Dateinamenserweiterung beschreibt. Diese Beschränkung ist in den Betriebssystemen CP/M von Digital Research (ab ca. 1974)<ref></ref> und davon abgeleiteten PC-kompatiblen Disk Operating Systemen (ab 1980) ebenso zu finden wie im {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value) (FAT), einem ursprünglich 1977 von Microsoft für BASIC entwickelten Dateisystem, das später über 86-DOS auch in MS-DOS übernommen wurde.

Durch die große Verbreitung von MS-DOS und Windows in den 1980er und 1990er Jahren war 8.3 lange Zeit die vorherrschende Konvention für Dateinamen und galt auch darüber hinaus bis in die 2000er Jahre als Industriestandard für den Datenaustausch zwischen den Plattformen.<ref name="linuxuser_2009_05_editorial">Jörg Luther: Weg mit dem FAT. In: LinuxUser 05/2009. Computec Media, 1. Mai 2009, abgerufen am 18. Februar 2021: „Tatsächlich kommt man an FAT kaum vorbei, besitzt man irgendein Gerät oder Gadget, das Dateien auf einem Wechselmedium speichert. Die Industrie hat das von Microsoft entwickelte Dateisystem millionenfach in Systemen implementiert, als so genannten Industriestandard…“</ref> Erst mit der LFN-Erweiterung durch VFAT (LFN steht für {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value), VFAT für {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value)), die mit Windows 95 und Windows NT 3.5 Mitte der 1990er Jahre eingeführt wurde, konnte die 8.3-Beschränkung bei Systemen, die auf dem FAT-Dateisystem basieren, aufgehoben werden.

Geschichte

Beim Betriebssystem CP/M, das Mitte der 1970er für Computer für die 8-Bit-Prozessoren Intel 8080 und Zilog Z80 entwickelt wurde, orientierte sich dessen Entwickler Gary Kildall an den Konventionen des Betriebssystems TOPS-10 für die DEC PDP-10.<ref></ref> Viele Systeme der späten 1960er und frühen 1970er Jahre hatten ein Limit von sechs<ref></ref> oder acht Zeichen für den Dateinamen. Auch gab es auf vielen dieser Systeme bereits eine Dateinamenserweiterung, die auf drei Zeichen beschränkt war.<ref></ref> Inspiriert vom 6.3-Limit von TOPS-10<ref>DECsystem-10: Getting Started With TOPS-10 Commands. (PDF; 2,4 MiB) 2.0 Files. In: DEC-10-0TSCA-A-D. Digital Equipment Corporation, Juni 1975, S. 4, abgerufen am 19. Oktober 2021 (Lua-Fehler in Modul:Multilingual, Zeile 153: attempt to index field 'data' (a nil value)): „Filenames are from one to six letters or digits. All letters or digits after the sixth are ignored. The filename extension is from one to three letters or digits. It is generally used to indicate the type of information in the file.“</ref> nutzt das Dateisystem von CP/M daher eine 8.3-Konvention.

Ab 1978 war mit dem 8086 der erste 16-Bit-Prozessor von Intel verfügbar, gefolgt von dessen voll kompatiblem kleineren Bruder 8088 ab 1979. Als der Nachfolger des 8-Bit-8080 waren ihm der 16-Bit-8086 bzw. -8088 so ähnlich, dass Assembler-Code meist mit nur wenigen kleinen Anpassungen neu übersetzt werden konnte; 8080-Binärcode war jedoch nicht kompatibel. Das Interesse am neuen 16-Bit-Prozessor war zwar groß, doch gab es keine kompatible Version des damals bereits verbreiteten Betriebssystems CP/M. 1980 schließlich begann der Entwickler Tim Paterson von Seattle Computer Products mit der Entwicklung eines nahezu identischen Systems namens QDOS, für „{{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value)“, das zwar keine 8-Bit-Programme ausführen konnte, CP/M jedoch in großen Teilen nachempfunden war. Als Dateisystem wählte Tim Petterson den bereits von Microsoft BASIC verwendeten {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value), der wie das Dateisystem von CP/M auch die 8.3-Konvention verwendete.

Durch den weiteren Verlauf der Geschichte wurde mit jedem IBM PC ab 1981 dieses 86-DOS genannte Betriebssystem als IBM PC DOS ausgeliefert, das Microsoft inzwischen gekauft hatte und das als MS-DOS zum Industriestandard auf allen IBM-PC-kompatiblen Computern der 1980er und frühen 1990er Jahre werden sollte. Mit CP/M-86 kam 1982 zwar CP/M endlich ebenfalls auf den 16-Bit-Prozessor des IBM PC, war aber teurer als MS-DOS/PC DOS und konnte sich nicht mehr durchsetzen. Als Weiterentwicklung von CP/M besetzte in den späten 1980er und frühen 1990er Jahren jedoch das zu MS-DOS kompatible DR DOS von Digital Research (später Novell DOS und schließlich wieder DR-DOS) eine kleine Nische im Markt der IBM-PC-kompatiblen Computer.

Aufgrund des großen Erfolgs des IBM-PC-Designs und der zahlreichen dazu kompatiblen Computer wurde FAT zum Industriestandard für den Datenaustausch mit anderen Systemen. Eine Vielzahl von Geräten, die einen Datenspeicher nutzen, verwenden ebenfalls FAT und sind somit von der 8.3-Beschränkung bzw. deren Implementierung in VFAT betroffen.<ref name="linuxuser_2009_05_editorial" />

Konvention

8.3 bedeutet, dass das Dateisystem bei Datei- und Verzeichnisnamen auf höchstens acht Buchstaben oder Ziffern, gefolgt von einem Punkt („.“) und der Namenserweiterung, die aus maximal drei Zeichen bestehen darf, limitiert ist. Bei der Verarbeitung der Datei- und Verzeichnisnamen wird dabei nicht zwischen Groß- und Kleinschreibung unterschieden. Ein 8.3-Dateisystem ist daher {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value). Kleinbuchstaben werden dazu vom Betriebssystem in Großbuchstaben umgewandelt, im Dateisystem sind Kleinbuchstaben dadurch prinzipiell unzulässig. Weiterhin sind einige Sonderzeichen unzulässig, die unter CP/M und MS-DOS als Steuerzeichen reserviert sind (z. B. Doppelpunkt, Fragezeichen, Stern) oder in unterschiedlichen Codepages unterschiedlich belegt sind, bspw. ist der Pfadbegrenzer in Deutschland (Codepage 850) der Backslash („\“) und in Japan (Codepage 932) das Yen-Symbol („¥“), obwohl ihre Dateisystem-interne Kodierung identisch ist.

Skriptfehler: Ein solches Modul „Vorlage:Anker“ ist nicht vorhanden.Kurze Dateinamen

Mit Windows 95 und Windows NT 3.5 wurde VFAT als Variante des FAT-Dateisystems mit erweiterten Verzeichniseinträgen eingeführt. Damit wurden längere, groß- und kleinbuchstabig geschriebene Dateinamen als sog. „{{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value)“ (abgekürzt LFN) zusätzlich zum 8.3-Schema auch in der MS-DOS-  (für MS-DOS gibt es DOSLFN<ref>Henrik Haftmann: Wozu DOSLFN, was ist das? Technische Universität Chemnitz, abgerufen am 16. April 2024.</ref>) und Windows-„Welt“ möglich. Die Schreibweise wird jedoch weiterhin vom Betriebssystem unabhängig von der Groß- und Kleinschreibung akzeptiert, sodass auch VFAT weiterhin {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value) ist, jedoch auch {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value), die bei der Erstellung einer Datei verwendete Schreibweise also erhält. Dies ist für die Abwärtskompatibilität mit bestehender Software notwendig.

Ebenfalls der Abwärtskompatibilität geschuldet wird für jeden langen Dateinamen zusätzlich eine klassische 8.3-Variante im Verzeichnis eingetragen, unter der ältere Programme mit derartigen Dateien umgehen können. Diese nun doppelten Einträge werden retronym auch {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value), {{Modul:Vorlage:lang}} Modul:Vorlage:lang:103: attempt to index field 'wikibase' (a nil value), genannt. Sie betreffen dabei nicht nur das FAT-Dateisystem, mit VFAT auf den Varianten FAT12, FAT16 und FAT32, sondern auch das modernere NTFS.<ref>Naming Files, Paths, and Namespaces – Short vs. Long Names. In: Windows Developer. Microsoft, abgerufen am 18. Februar 2021 (Lua-Fehler in Modul:Multilingual, Zeile 153: attempt to index field 'data' (a nil value)): „A long file name is considered to be any file name that exceeds the short MS-DOS (also called 8.3) style naming convention. When you create a long file name, Windows may also create a short 8.3 form of the name, called the 8.3 alias or short name, and store it on disk also.“</ref><ref name="MS-Q130694" />

Unter Windows wird hierzu folgendermaßen vorgegangen:

  1. Wenn der Dateiname bereits nur aus Großbuchstaben bzw. Ziffern im 8.3-Schema besteht, wird keine LFN-Variante erzeugt.
    Beispiel: TEXTFILE.TXT
  2. Wenn der Dateiname zwar dem 8.3-Schema entspricht, aber Groß- und Kleinbuchstaben enthält, wird dies als LFN gespeichert, während zusätzlich eine großgeschriebene 8.3-Variante ({{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value)) erzeugt wird.
    Beispiel: TextFile.Txt wird zusätzlich als TEXTFILE.TXT registriert.
  3. Sonstige Dateinamen werden als LFN gespeichert und zusätzlich wird eine 8.3-Variante, genannt {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value) für „kurzer Dateiname“, registriert. Da beide Einträge auf dieselben Daten verweisen, entspricht dies einer harten Verknüpfung, die jedoch automatisch vom Betriebssystem bzw. Dateisystem-Treiber verwaltet wird. Es gibt daher keine Möglichkeit, in diesen Vorgang einzugreifen. Der kurze Dateiname besteht aus den ersten 6 Zeichen des Dateinamens in Großbuchstaben, erweitert um eine Tilde („~“) und eine fortlaufende Ziffer, gefolgt vom Punkt und den ersten drei großgeschriebenen Zeichen der Namenserweiterung.
    Beispiel a): TextFile1.Mine.txt wird zu TEXTFI~1.TXT (oder TEXTFI~2.TXT, falls TEXTFI~1.TXT bereits existiert).
    Beispiel b): WordFile1.docx wird zu WORDFI~1.DOC (oder WORDFI~2.DOC, falls WORDFI~1.DOC bereits existiert).
  4. Wenn die vorangehenden Methoden nicht zu einem eindeutigen 8.3-Dateinamen führen, wird der lange Dateiname (LFN) auf zwei Zeichen gekürzt, gefolgt von einer zufälligen 4-stelligen Hexadezimalzahl, der wiederum eine Tilde samt Ziffer folgt und woran anschließend die Namenserweiterung angehängt wird.
    Beispiel: TextFile.Mine.txt könnte zu TE021F~1.TXT werden.

Auch auf anderen Betriebssystemen ist diese Funktion oft vorhanden, kann aber teilweise auch beeinflusst werden. Unter Betriebssystemen, die traditionell eher die Kleinschreibung bevorzugen wie etwa Unix und Unix-artige Betriebssysteme, gibt es daher auch oft die Möglichkeit, 8.3-Dateien für den Zugriff automatisch in die Kleinschreibung umzuwandeln, obwohl sie der 8.3-Konvention folgend im Dateisystem in Großbuchstaben abgespeichert sind. Dies macht bei der unter Unix üblichen {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value)-sensitiven Nutzung einen wesentlichen Unterschied, denn dadurch ist z. B. FILENAME.TXT nur als filename.txt ansprechbar. Unter Linux kann das genaue Verhalten für den Dateisystemtreiber vfat durch verschiedene Mount-Optionen festgelegt werden: Die Konvertierung der Großbuchstaben bei 8.3-Dateinamen in die entsprechende Kleinschreibung ist über den Parameter shortname einstellbar, und für die bei LFN automatisch erzeugten kurzen Dateinamen ermöglicht die Option nonumtail, dass diese nach Möglichkeit einfach nach den ersten acht Zeichen abgeschnitten werden. Damit würde LangerDateiname.txt zu LANGERDA.TXT, falls dieser 8.3-Name noch verfügbar ist, bevor LANGER~1.TXT versucht wird.

Auf allen Betriebssystemen werden die kurzen 8.3-Namen bei Dateioperationen in jedem Verzeichnis neu generiert. Da dies transparent und automatisch passiert, kann es bei mehreren ähnlichen Dateinamen zu einer veränderten Nummerierung beim kurzen Dateinamen aufgrund der Reihenfolge der Abarbeitung kommen, z. B. wenn Dateien kopiert oder verschoben werden. Beispiel: Es wird zuerst Meine Datei.txt erstellt, welche den Kurznamen MEINED~1.TXT erhält. Danach wird Meine Daten.txt erstellt, welche MEINED~2.TXT erhält. Wird die zweite Datei als erstes in ein neues Verzeichnis kopiert oder verschoben, erhält Meine Daten.txt den Kurznamen MEINED~1.TXT und die als zweite kopierte Meine Datei.txt den Kurznamen MEINED~2.TXT. Für den Anwender ist bei den allermeisten automatischen Dateioperationen, z. B. wenn mehrere Dateien markiert und kopiert oder verschoben werden, die Reihenfolge der Abarbeitung generell unvorhersehbar.

Probleme können entstehen wenn Dateien ihren langen Dateinamen verloren haben (beispielsweise Bearbeitung mit alten Programmen, Weitergabe über nicht kompatible Systeme) und eine LFN-Datei mit diesem Namen als Kurznamen schon existiert. Dann wird gefragt ob die Datei überschrieben werden soll. Dies kann auch passieren, wenn beide Dateien vorher friedlich in einem gemeinsamen Verzeichnis existierten. Beispiel: In einem Verzeichnis existiert bereits die Datei MEINED~1.TXT. Dazu kommt eine Datei mit dem Namen Meine Datei.txt, welche automatisch den Kurznamen MEINED~2.TXT erhält, da „~1“ schon vergeben ist. Wird jetzt in der Abarbeitungsreihenfolge zuerst Meine Datei.txt bewegt (weil beispielsweise nach Dateidatum abgearbeitet wird) erhält sie den Namen MEINED~1.TXT. Bei der nachher bewegten MEINED~1.TXT, welche nur diesen und keinen langen Dateinamen hat, wird dann festgestellt, dass der Dateiname schon vergeben ist. Gefährlich ist es nun in einer grafischen Dateioperation, wenn der Benutzer kurzerhand auf „Überschreiben“ klickt, denn damit geht eine der beiden Dateien verloren (wird im Endresultat beim Verschieben gelöscht).

Das NTFS-Dateisystem der Windows-NT-basierten Windows-Versionen unterstützt ebenfalls das LFN-System, es werden daher auch immer kurze Dateinamen im 8.3-Schema automatisch erstellt, was ebenfalls der Abwärtskompatibilität geschuldet war. Obwohl der Tipp, kurze Dateinamen für NTFS generell abzuschalten, gelegentlich sogar von Medien und Fachzeitschriften aufgegriffen wurde,<ref>Sebastian Kolar: Windows 7/8/10: Speichern von 8+3-Dateinamen deaktivieren. In: Computer Bild. 11. April 2020, abgerufen am 16. April 2024.</ref> empfiehlt dies Microsoft nur für Datei-Server<ref>Windows Server – Performance Tuning NFS File Servers. In: Microsoft Learn. Microsoft, 30. August 2021, archiviert vom Vorlage:IconExternal am 6. Februar 2023; abgerufen am 16. April 2024 (Lua-Fehler in Modul:Multilingual, Zeile 153: attempt to index field 'data' (a nil value)): „The system volume has 8dot3 enabled by default. All other volumes in Windows Server 2012 and Windows Server 2012 R2 have 8dot3 disabled by default. … For most file servers, the recommended setting is 1 (disabled).“</ref> u. a. zwecks Erhöhung der Abarbeitungsgeschwindigkeit<ref name="MS-Q130694">NTFS Performance with Numerous Long Filenames. In: Knowledge Base. Microsoft, 1. November 2006, archiviert vom Vorlage:IconExternal (nicht mehr online verfügbar) am 18. August 2007; abgerufen am 16. April 2024 (Lua-Fehler in Modul:Multilingual, Zeile 153: attempt to index field 'data' (a nil value)): „When you save a file with a long file name to an NTFS drive, NTFS creates, by default, a second file directory entry with a short file name conforming to the 8.3 convention. When NTFS enumerates files in a directory, it has to look up the 8.3 names associated with the long file names. Because an NTFS directory is maintained in a sorted state, corresponding long file names and 8.3 names are generally not next to one another in the directory listing. … the amount of time required to perform a directory listing increases with the square of the number of files in the directory. For small numbers of files (less than a few hundred) the time delay is negligible. But as the number of files in a directory increases to several thousand, the time required to perform a listing can increase to minutes, hours, or even days. The problem is aggravated if the long file names are very similar – differing only in the last few characters.“</ref> – der Effekt ist aber wohl ziemlich gering.<ref>Helge Klein: Why Disabling the Creation of 8.3 DOS File Names Will Not Improve Performance. Or Will It? (Blog) 22. September 2008, abgerufen am 16. April 2024 (Lua-Fehler in Modul:Multilingual, Zeile 153: attempt to index field 'data' (a nil value)).</ref>

Unter Windows NT kontrolliert das DWORD32 NtfsDisable8dot3NameCreation unter HKEY_LOCAL_MACHINE\​SYSTEM\​CurrentControlSet\​Control\​FileSystem in der Registrierungsdatenbank die zusätzliche Erstellung der kurzen Dateinamen auf NTFS-Laufwerken. Hat der Eintrag den Wert 0, was der Standard unter allen früheren Windows-NT-Versionen war, so werden 8.3-Dateinamen auf allen NTFS-Laufwerken automatisch erstellt. Der Wert 1 deaktiviert die zusätzlichen kurzen Dateinamen. Moderne Windows-Versionen erstellen kurze Dateinamen nur noch auf dem Systemlaufwerk (Wert 2),<ref name="heiseonline_7338747">Hajo Schulz: FAQ: Ordner und Dateinamen unter Windows entwirren. In: Heise online. 20. November 2022.Vorlage:Abrufdatum; Zitat: „8 plus 3 … Moderne Windows-Installationen speichern diese 8.3-Namen gar nicht mehr auf allen Laufwerken. Wo Sie bei Ihnen noch aktiv sind, verrät das Programm fsutil.“.</ref> wo sie allerdings auch durchaus noch in Verwendung sein könnten, z. B. in der Registrierungsdatenbank.<ref name="heiseonline_7244338">Hajo Schulz: Windows-Dateisystempflege mit fsutil: Kommandozeilenwerkzeug in der Praxis. In: Heise online. 6. September 2022 (Paywall: c’t 19/2022, S. 158, „Feinwerkzeug“).Vorlage:Abrufdatum; Zitat: „Auf allen Systemen, die uns in freier Wildbahn untergekommen sind, war Option 2 gewählt und das Speichern von 8.3-Namen auf dem Systemlaufwerk aktiv. Wer auf die Idee kommt, den Overhead für die Verwaltung der historischen Dateinamen loszuwerden, sollte einiges beachten: Anwendungen, die nur mit solchen Dateinamen arbeiten können, werden wohl nicht mehr im Einsatz sein. Allerdings gibt es durchaus noch Programme (und vermutlich auch vereinzelte Windows-Komponenten), die beim Speichern von Verweisen auf bestimmte Dateien in der Registry das 8.3-Format verwenden.“.</ref> Alternativ kann das ab Windows XP mitgelieferte Programm fsutil<ref>Datenträgerkontingente über die Kommandozeile verwalten. In: WinFAQ. Frank Ullrich, 2016, abgerufen am 16. April 2024: „Ab Windows XP gibt es ein neues Tool „FSUTIL.EXE“, mit dem Sie über die Datenträgerkontingente das Dateisystem bearbeiten können.“</ref> verwendet werden, um diesen Wert festzulegen: fsutil behavior set disable8dot3 <Wert>.<ref>Fehlermeldung auf einem Windows Server 2003-basierten Computer: Fehlercode beenden 0x00000019. In: Windows Server Docs. Microsoft, 24. September 2021, archiviert vom Vorlage:IconExternal am 9. Mai 2022; abgerufen am 16. April 2024 (maschinell übersetzt).</ref> Auf bestehende Dateien haben diese Änderungen keinen Einfluss.

Auf den Nachfolge-Dateisystemen exFAT und ReFS wird das LFN-System nicht mehr unterstützt, sodass auch keine kurzen Dateinamen mehr automatisch zu den regulären „langen“ Namen erstellt werden.

Das von CDs genutzte Dateisystem ISO 9660 erlaubt zwar Dateinamen mit bis zu 31 Zeichen, allerdings wurde früher aus Kompatibilitätsgründen von vielen Brennprogrammen auch hier das 8.3-Namensschema genutzt.

Einzelnachweise

<references />