Diskussion:Dateiname

Diese Diskussionsseite dient dazu, Verbesserungen am Artikel „Dateiname“ zu besprechen. Persönliche Betrachtungen zum Thema gehören nicht hierher. Für allgemeine Wissensfragen gibt es die Auskunft.

Füge neue Diskussionsthemen unten an:

Klicke auf Abschnitt hinzufügen, um ein neues Diskussionsthema zu beginnen.

• Diskussionsregeln
• Hilfe zu Diskussionsseiten
• Sei sachlich und freundlich!
• Greife niemanden persönlich an!
• Geh von guten Absichten aus.

[[1]]

Die Definition von Pfadname im Absatz Unix widerspricht der Definition im Artikel Pfadname. Ein Pfadname gemäß Absatz entspricht einem Segment eines Pfadnames gemäß Artikel. Ich programmiere in PHP einen URL Parser, wobei bereits in dieser Programmiersprache die Bezeichner je Befehl instringent sind. Mein Vorschlag: eine hierarchische Liste im Artikel URL, die die Segmente einer URL (samt Pfadnamen...) eindeutig bezeichnet. -- 80.108.107.62 16:45, 13. Okt. 2009 (CEST)

DateiSystem Unterschiede

"Ein Unterschied zwischen MS Windows und Linux/Unix besteht darin, dass Windows bei Dateinamen nicht zwischen Groß- und Kleinschreibung unterscheidet, während Unix dies tut (z.B. bezeichnen dort Haustür.txt und hausTür.txt unterschiedliche Dateien)." Das ist soweit richtig, daß zwischen Groß- und Kleinschreibung unterschieden wird. Allerdings ist das keine Eigenheit von Linux/Unix, sondern es liegt am verwendeten Dateisystem. Ich weiß nicht, ob es nicht für Linux auch caseinsensitive Dateisysteme gibt. Es stehen ja eine ganze Menge an verschiedenen Dateisystemen zur Auswahl... Und wenn man unter Linux mit FAT32 arbeitet, dann dürfte hier eigentlich auch nicht zwischen Groß- und Kleinschreibung unterschieden werden.

mehr als nur einen Namen pro Datei?

Ich hab hier bei W2000 eine seltsame Erscheinung:

wenn ich meine Datei _+ Diary 08_01.rtf per Explorer und Anklicken öffne - dann steht im oberen Fensterrahmen der angebliche Dateinamen __3999~1.RTF . Hole ich mir per Menü die Maske "Abspeichern unter...", steht darin ebenfalls __3999~1.RTF vorgegeben; und wenn ich bestätige, warnt er: "dieser Dateiname ist schon vorhanden - überschreiben ??" Dabei ist dieser Dateiname gar nicht im Verzeichnis! Bestätige ich, so taucht im Verzeichnis nicht der Pseudo-Dateiname auf, sondern der ursprüngliche, mit aufdatiertem Zeitstempel. Es kann also wohl nicht sein, dass der ursprüngliche Dateiname bei einem Bearbeitungsschritt schlicht "kaputtgegangen" ist und jetzt der neue weiterverwendet wird, sondern es gibt weiterhin eine Kenntnis des ursprünglichen Namens, die auch genutzt wird.

Eine andere Datei wird in gleicher Weise "teil-umgetauft" in __168D~1.RTF es könnte sich also um Hex-Zeichen handeln.

Dieses Verhaltensmuster ist aber nicht durchgängig. Klicke ich jetzt im Verzeichnis auf einen anderen Dateinamen, wird der unverändert benutzt. Das gleiche gilt, wenn ich eine Testdatei neu erschaffe (auch mit mehr als 8 Zeichen im Namen) und dann öffne.

Ein echter Datenschaden ist also anscheinend nicht da; aber lästig ist es schon, wenn man dem Fensterrahmen den Dateinamen entnehmen möchte und nur krauses Zeug angedient kriegt.

Meine Idee: Gibt es bei W2000 evtl. zu einer Datei außer dem offiziellen auch einen "Arbeitsnamen", der "unterirdisch" benutzt wird und manchmal versehentlich an der Oberfläche aufblitzt?

Kenntnisfrei, 213.102.106.82 12:26, 18. Jan. 2008 (CET)

Hallo und oha.

Zuerst musst du dieses Bapperl über dich ergehen lassen:

Das von dir beschrieben Verhalten ist ziemlich kurios. Es gibt in Windows keine "unterirdischen" - internen Bezeichnungen für Dateien. Der Effekt kommt zustande, wenn aus irgend einem Grund der Dateiname nicht vom Dateisystem unterstützt wird. Dies war in früheren Zeiten oftmals mit den berühmten 8+3-Dateinamen der Fall, wo Dateinamen mit mehr als acht Zeichen im eigentlichen Namen (sprich abgesehen von der Erweiterung) auf acht Zeichen gekürzt wurden, indem ein Teil hinten abgeschnitten und dann mit ~X durchnummeriert wurde. Das ist offenbar auch hier passiert. Allerdings nicht von Seiten des Dateisystems aus, sondern offenbar von Seiten des Anwendungsprogramms, mit dem du die Datei öffnest - was für ein Programm ist das, und wie alt ist es? Es ist möglich dass das Programm nur 8+3 unterstützt - wäre aber auch sehr verwunderlich. Eine andere Mölichkeit ist, dass im Dateinamen Zeichen verwendet werden, die das Programm nicht mag und es deshalb auch wieder in einen generischen Namen umwandelt - und weiss gott, ich könnte es ihm nicht verübeln - Unterstriche sind ja ok, aber bei + und Leerzeichen... ich weiss ja nicht - hast du schonmal probiert, die Datei einfach umzubenennen, und den grässlichen Präfix wegzunehmen? Wenn du die Datei über den Namen in eine besondere Sortierung bringen willst, würde ich dir eher ein paar mehr Unterordner empfehlen, oder die Verwendung von Ziffern am Anfang des Namens. HTH --Schmiddtchen 说 12:43, 18. Jan. 2008 (CET)

Also zuerst mal Danke dafür, dass du dein Hirnschmalz in meine Frage investierst, Schmiddtchen! Allerdings finde ich das "Bapperl" fehl am Platze, denn wenn da tatsächlich eine "unterirdische" Struktur am Wirken wäre, wäre das ja sehr wohl eine Eigenschaft gewesen, die mit Dateinamen direkt zu tun hat, aber im Text noch nicht berücksichtigt ist; also von daher eine Erweiterung der Information zum Artikeltitel! (Wenn es natürlich auch irgendwo "mein" Problem ist, da ich davon betroffen bin.)

Zur Sache: Dein Hinweis auf das öffnende Programm hat mich zuerst eher verwirrt (ich dachte, du meinst den Windows Explorer); dann hab ich Wordpad, das ich fast immer benutze, mal systematisch auf Zeichen im Namen getestet (ich dachte, was nicht verboten ist, sei erlaubt - etwas komisch, wenn das anders geregelt ist), und das kam raus:

• mit Wordpad wird in der Tat ggf. umbenannt, in die von dir bezeichnete DOS-Norm, alles in Großbuchstaben;
• (ich lasse die ".rtf" mal weg)

• ein "+" im Namen (irgendwo) scheint die Übersetzung auszulösen;
• dabei wird bei kurzen Namen das "+" zu einem "_" konvertiert, der Rest beibehalten, und auf 8-Zeichen DOS-"verkürzt" (z. B. wird aus "+a" "A_776D~1");
• lange Namen werden ganz übersetzt
• aus "a+" wird "A_9E36"; aus "a+ " wird "A_A631~1"; aus "a+ " wird "A_CCF7~1": Leerzeichen gehen in die Übersetzung mit ein

• ein Unterstrich macht keine Probleme, auch nicht vorn;

• auch ein Leerzeichen im Namen löst die DOS-"Verkürzung" aus;
• dabei wird es einfach weggelassen;
• der Rest wird bei langen Namen regulär "8-Zeichen-DOS-verkürzt";
• das passiert auch bei kurzen Namen wie "a b"; allerdings wird bei der "Verkürzung" verlängert: "AB9E34~1"

Dabei werden die Namensübersetzungen nicht einfach nach Zufall gebildet (hash), sondern determiniert. Es liegt also eine Funktion vor. Vermutlich eine injektive, da die "Rückübersetzung" immer geklappt hat. Es ist hier also in der Tat unter der Oberfläche irgendwas zielgerichtet am arbeiten.

Notepad dagegen beläßt den TXT-Dateien ihre Originalnamen, auch wenn sie die "heiklen" Plus- oder Leerzeichen enthalten.

An der Stelle denkt man, es liegt also wohl an Wordpad.

Aber jetzt hab ich spaßeshalber mal ein paar richtig "üble" TXT-Namen-Dateien geöffnet MIT WORDPAD - und siehe da: Namen 1:1 übernommen!!!

Es scheint also nicht am öffnenden Programm zu liegen (deine Überlegung brachte mich auf die Idee), sondern irgendwie am Dateiformat!

(Leider hab ich kein Word, um das mit weiteren Programmen zu checken.)

Vorstellbar wäre aber wohl auch ein Virus, der speziell Wordpad befällt (unter NT4 hatte ich mal die Erscheinung, dass formatierte Texte unter Wordpad aus .rtf-Dateien heraus nicht mehr zu exportieren gingen.) Ein Scan (ganzes System, vollster Umfang) mit Antivir bringt aber keinen Fund.

Und das Verrückte ist ja auch, dass die Veränderungen beim Abspeichern wieder rückgängig gemacht werden (wie beschrieben)! Warum sollte ein Virus sich auch die Mühe machen, erst den RTF-Namen beim Bearbeiten abzuändern und dann beim Abspeichern wieder den Originalnamen abzuspeichern? Und sich auch noch die Mühe macht, dies vom Dateityp her abhängig zu machen?

Ich hab sonst auch keine Probleme, die nach Viren aussehen. Das einzige ist, dass ich beim (endgültigen) Abspeichern in die WP die Seite nicht mehr zur Kontrolle gezeigt kriege; das Display bleibt weiß. Und wenn ich auf einer WP-Seite bin und über das Such-Fenster einen neuen Begriff ansteuern will, dann wird auch da der Schirm nur weiß.

Dies könnte ich mir aber damit erklären, dass ich nach der Installation des W2000 (mit SP 2) zum Portabdichten das CCC-Skript in der restriktivsten Version laufengelassen habe, und die WP-Methode nicht völlig stubenrein ist, so dass hier unterbunden wird.

Aber ein Bug in Wordpad, der Dateinamen auf DOS-Norm umstrickt, sich aber den Originalnamen merkt und zum Schluss wieder unter diesem abspeichert (obwohl er vorgibt, es unter dem Ersatznamen abspeichern zu wollen), und dieses aber alles nur für das RTF-Format, nicht aber bei TXT, fände ich aber auch schon höheren Zufall. Und ich kann mich auch nicht erinnern, dass mir sowas mal in NT4-Wordpad untergekommen wäre. Klar ist eine Verschlimmbesserung nicht auszuschließen; aber die große Mehrzahl der Fälle ist doch wohl, dass es, wenn es funktioniert, auch in der nächsten Generation funktioniert.

Also ich bin noch nicht ganz überzeugt, dass es nichts mit Dateinamen zu tun haben soll.

Mal in die Breite gefragt: Hat denn niemand sonst ähnliche Erfahrungen gemacht??

Danke auch für die Tips bzgl. Namensalternativen; die sind in meinem Fall aber wenig praxisgerecht, da ich viele neue Dateien unter Zeitdruck erzeugen muß. Unterverzeichnisse sind schon ohne Ende da; aber ich hab nicht jedesmal die Zeit, in denen herumzuturnen. Ein Präfix, der angibt, wohin die Datei gehört, ist da segensreich: man kann dann zum Schluss das Dateien-Sammelbecken einfach alfabetisch ordnen, und dann mit einem Schlag etwa 30 Dateien mit "§" zu "Rechtliches" ziehen, mit "$" zu "Wirtschaft", mit "&" auf "Soziales/Politik", mit dem Pfundzeichen auf "Medizinisches" (Symbol für die "Äskulapschlange"); usw. Ein Zahlensystem ginge theoretisch auch, wäre aber Gedächtnisballast (das Gedächtnis ist ja endlich, und man wird heute ja so mit Merk-Daten zugesch...), während die Symbolzeichen mit einfachen Assoziationen intuitiv zu verstehen sind; und wenn der eigentliche Dateinamen selbst schon mit Zahlen anfängt...

So, das ist jetzt (trotz Zusammenfassungen) ein ziemlicher Roman geworden; aber wenn man begründen will, muss man halt Material bringen.

Gruß, Kenntnisfrei

(nicht signierter Beitrag von 213.102.99.148 (Diskussion | Beiträge) 14:48, 23. Jan. 2008 (CET))

Zu diesem Verhalten kommt es auch, wenn der Gesamt-Pfad im entsprechenden Dateisystem zu lange ist. (Etwa wenn man einen langen Pfad auf eine CD speichern möchte, oder eine Ordner-Hierarchie in einen anderen Unterordner kopiert, so dass sich die Pfad-Länge addiert. Dann kürzt Windows den langen Namen auf eine kürzere 8+3 Form, die per Voreinstellung noch unsichtbar nebenher angelegt wird. -- 80.108.107.62 17:07, 27. Okt. 2009 (CET)

Hallo. Nach kurzer Suche auf Microsoft TechNet fündig geworden: File Systems (englisch).

Es ist nunmal so programmiert worden, dass bei gleich lautenden Anfangsbuchstaben der kurze Dateiname beliebig durchnummeriert wird. Der kurze Dateiname ist zwar oft an den langen Dateinamen angelehnt, das muss aber nicht sein. Bei vielen Unicode-Zeichen generiert Windows im Normalfall sogar einen völlig anderen, aus Zufallszeichen erstellten kurzen Dateinamen.

Ich muss mich daher Schmiddtchen anschließen. Wikipedia ist kein Forum.

Es mag dem ursprünglichen Ersteller dieses Diskussionsabschnitts zwar als erwähnenswert erschienen sein, aber es handelt sich tatsächlich um ein ganz normales Verhalten von Windows.

Gruß, ‣Andreas•⚖ 10:05, 28. Okt. 2009 (CET)

Maximale Länge von Dateinamen unter Windows XP Professional SP3

Ich habe folgendes Phänomen unter dem Betriebsystem Windows XP Professional SP3 mit NTFS:

Eine Datei mit dem folgenden Namen

"C:\Dokumente und Einstellungen\user\Eigene Dateien\Temp\12-inbox\diesist ein ehlend langer dateiname und wird auch immer längerdiesist ein ehlend langer dateiname und wird auch immer längerdiesist ein ehlend langer dateiname und wird auch immer länger bis .eml"

lässt sich nicht erstellen bzw. eine bestehende Datei nicht so umbenennen. Es wird vielmehr eine Datei erstellt bzw. umbenannt, wobei das letzte Zeichen "l" nicht mehr angenommen wird. Noch längere Namen werden ebenfalls nicht akzeptiert.

Die absolute Länge einschl. Laufwerkbuchstabe beträgt demnach 259 Zeichen!?

Also, das sind ganz bestimmt nicht 255 je Pfadebene, wie hier beschrieben.

-- 14:23, 19. Okt. 2008 (CEST)

Allgemeinverständlichkeit

Der Unterschied 8+"."+3 / 255 Zeichen wird nicht allgemeinverständlich erläütert. --85.178.155.8 09:29, 10. Nov. 2008 (CET)

Was meinst du damit? Welchen Teil des Abschnitts verstehst du nicht? --j ?! 17:56, 10. Nov. 2008 (CET)

Zur Wahrung der Kompatibilität mit alten MS-DOS-Programmen kann der Dateiname auch in der sogenannten 8.3-Notation angegeben werden. - mehr ist dazu imho nicht zu sagen. -- Nolispanmo Disk. Hilfe? 10:35, 11. Nov. 2008 (CET)

Codepage

Dass FAT ohne VFAT die Codepage 437 verwendet ist Blödsinn, es werden einfahc ganz normale 8bit-Zeichen verwendet,, also im Bereich 0x00-0x7F ASCII und außerhalb dieses Bereichs wird die gerade installierte Codepage verwendet, es muß also nicht Codepage 437 sein, man kann z.B. genauso Codepage 850 verwenden. Die Darstellung des Dateinamens hängt halt von der Codepage ab, d.h. wenn man in DOS Codepage 850 eingestellt hat, die datei speichert und sie nachher in einem DOS mit Codepage 437 öffnet, wird man was anderes lesen, als das, was man ursprünglich eingegeben hat. --MrBurns 00:50, 14. Nov. 2008 (CET)

Stimmt. Ich hab's etwas umformuliert. -- Gerd Fahrenhorst 22:28, 14. Nov. 2008 (CET)

Der Artikel kann nur als Müll bezeichnet werden

Er ist voll von groben Fehlern und wird nicht einmal in der ersten Zeile seinem Thema gerecht.

Da mit dem Wort Dateiname normalerweise ein Pfadnamenkomponente bezheichnet wird, identifiziert ein Dateiname schonmal definitiv nicht eine Datei auf einem Datenträger, sondern höchstens innerhalb einer Directory.

Dann fällt beim Lesen auf, daß anscheinend NTFS nur kürzere Pfadnamen unterstützt als Dateinamen. Das ist offenbarer Unsinn, denn ein Pfadname ist die längste Zeichenfolge, die man dem Betriebssystem übergeben kann. Dateinamen, die länger als der maximale Pfadname sind, lassen sich nicht erzeugen.......

Beim weiteren Lesen finden sich viele weitere Fehler oder Ungenauigkeiten, deren Auflistung im Einzelnen den Rahmen sprengen würde. --Schily 11:12, 13. Jan. 2011 (CET)

Hinweis: Die maximale Länge des Pfades ist eine Eigenschaft des Betriebssystems, nur die Dateinamenlänge (also die Länge einer einzelnen Pfadnamenkomponente) ist eine Eigenschaft des Dateisystems. --Schily 11:11, 7. Feb. 2011 (CET)

Maximale Dateinamenlänge

Im Artikel steht dazu zumindest für WinDOS entweder Unsinn, oder NTFS hat eine hohe Wahrscheinlichkeit bei einem Systemabsturz nicht reparable Dateisysteme zu erzeugen. Soviel Unprofessionalität würde ich aber selbst bei Microsoft nicht annehmen wollen.

Ein Dateiname muß (zusammen mit den anderen Anteilen des Directoryeintrages) in einen Sektor der Festplatte passen, damit dieser Eintrag atomar geschrieben werden kann. Da Microsoft aber pro Zeichen zwei Oktette schreibt und die aktuelle Sektorgröße 512 Byte (Oktette) beträgt, kann NTFS wohl nur weniger als 256 Zeichen im Dateinamen verarbeiten. Berechnungsgrundlage: 512 - sonstige Anteile des Directoryeintrages (Verkettung, Inode, ...) geteilt durch 2. --Schily 13:30, 14. Feb. 2011 (CET)

Leerzeichen

Auch das Leerzeichen ist unter DOS verboten. --MrBurns (Diskussion) 22:09, 2. Dez. 2012 (CET)

Stimmt, ich habe das ergänzt. -- Gerd Fahrenhorst (Diskussion) 11:38, 3. Dez. 2012 (CET)

reservierte Zeichen

So viel ich wies gibt es unter DOS mehr reservierte Zeichen als dies: < > ? " : | \ / * ZB. geht auch = oder ; nicht. (nicht signierter Beitrag von 84.74.211.194 (Diskussion) 17:34, 1. Jan. 2015 (CET))

Gültige Zeichen in DOS-Dateinamen:

• die Buchstaben A-Z (wird in DOS ohne LFN immer in Großbuchstaben gespeichert)
• die Ziffern 0-9
• diese Sonderzeichen: $ # & @ ! ( ) - { } ' _ ~ ^

Ungültige Zeichen für DOS-Dateinamen:

• ASCII-Steuerzeichen
• Leerzeichen
• diese Sonderzeichen: = / [ ] " : ; , ? * \ < > |

Quelle: Using MS-DOS 6.22, Jim Cooper (Google Books)

Weitere Quelle (als Blog jedoch eher problematisch, daher unzulässig): DOS Lesson 7: DOS Filenames; ASCII, Ahuka Communications

‣Andreas•⚖ 18:22, 1. Jan. 2015 (CET)

Länge des Dateinamens

Unklar ist im Artikel, worauf sich die Längenangaben beziehen:

• auf den Tei vor dem Punkt im Dateinamen
• auf den Teil vor dem Punkt im Dateinamen plus Punkt plus Dateinamenerweterung
• auf den gesamten Teil vor dem Punkt im Dateinamen incl. Laufwerk und Pfad plus Punkt plus Dateinamenerweterung
• ...

Das geht in den verschiedenen Sätzen/Abschnitten/Tabellen durcheinander.
Eine konsistent eindeutige Benennung wäre erforderlich.
Gruss, --Markus (Diskussion) 07:35, 15. Jan. 2015 (CET)

Bitte ein Beispiel angeben, wo das angeblich „durcheinandergeht“. Soweit ich den Artikel durchgesehen habe, wird das immer klar angegeben. Das Problem ist eher, dass die Realität nicht leicht nachvollziehbar ist, weil sich verschiedene Betriebssysteme unabhängig voneinander entwickelt haben. Die 8.3-Beschränkung gab es bei Dateisystemen, die später als Unix eingeführt wurden, wo Punkte und die Zahl davor/dahinter noch nie eine Rolle gespielt hatten. --Lückenlos^wecken! 22:36, 25. Mär. 2015 (CET)

Unix ist kein Dateisystem. Man braucht auch unter Unix einen FAT-Treiber, der VFAT unterstützt. Wenn man das nicht hat, kann Unix bei FAT-Partitionen auch nur 8.3, was aber nur bei sehr alten Versionen der Fall sein dürfte (ziemlich sicher Versionen, die vor den ersten Windows-95-Betas erschienen und danach nicht upgedated wurden, da VFAT erst mit Win 95 eingeführt wurde). --MrBurns (Diskussion) 00:58, 26. Mär. 2015 (CET) PS: 8.3 ist älter als DOS, DOS hat 8.3 verwendet, um die Kompatibilität mit CP/M zu verbessern. --MrBurns (Diskussion) 01:01, 26. Mär. 2015 (CET)

Ich weiß jetzt auch nicht genau, was Markus genau meint. Aber ich kann mir vorstellen, dass es ihn verwirrt, dass einmal vom Dateinamen (ohne Pfadangabe) mit einem Limit die Rede ist, dann aber wieder von einem gesamten Pfad (inklusive Dateinamen). Und das ist jetzt ja nicht unbedingt ein Limit des Dateisystems, sondern eines des Betriebssystems – ein anderes Betriebssystem könnte theoretisch andere Limits haben, obwohl das Dateisystem die Dateinamen damit dann auch korrekt speichert.

Beispiel: Windows limitiert einen vollständigen Dateinamen inklusive Pfad in der im Windows-API definierte MAX_PATH-Konstante, also mit 260 Byte. Daraus ergibt sich (laut Microsoft) eine maximale Länge des Dateinamens von 256 Zeichen – allerdings nur, wenn die Datei im Wurzelverzeichnis eines Laufwerks liegt: D:\<Dateiname mit 256-Zeichen><NUL> Mit Unterverzeichnis sieht das dann so aus: D:\<Pfad einer bestimmten Länge>\<Dateiname mit 256-Zeichen minus Länge des Unterverzeihnisnamens minus 1 für den Backslash><NUL>. Interesanter Weise hängt das Limit unter Windows jedoch vom individuell genutzten Programm ab: nutzt ein Programm nämlich die Unicode-Variante der Befehle in der Windows-API, so ist das Limit nicht 260 Zeichen sondern 32.767 Zeichen. (Quelle hier) Ich denke jedoch, wenn Microsoft von Zeichen speicht, sind eigentlich Bytes, also der Datentyp char mit 8-Bit/1-Byte Größe gemeint, was bedeutet, dass bei Unicode tatsächlich weniger Zeichen zur Verfügung stehen würden.

Anderes Beispiel: Unter Linux ist ein vollständiger Dateiname inklusive Pfad mit 4.096 Bytes limitert (Quelle hier). Das gilt aber, wie unter Windows auch, für alle Dateisysteme, die in einem System eingebunden sind.

Mit anderen Worten: es existieren zwei Limits:

1. Das Dateisystem limiertiert die maximale Größe eines Dateinamens, was daran liegt, das der Speicherbereich zum Speichern des Dateinamens auch verfügbar gemacht werden muss, und dieser hat aus programmiertechnischen Gründen eben einen maximalen Wert, heißt: eine maximale Größe, heißt: eine maximale Länge des Dateinamens.
2. Das Betriebssystem limitiert die maximale Größe eines ansprechbaren und damit vollständigen (inklusive Pfad) Dateinamens. Das hat ebenfalls programmiertechnische Gründe, ist aber bei jedem Betriebssystem unterschiedlich. Leider hat es auch Einfluss auf ein Dateisystem und dessen Limits, inklusive der maximalen Länge eines Dateinamens.

Das kann schon sehr verwirrend sein, weil der Teufel steckt im Detail.

Leider kann nur Markus bestätigen, ob es das war, was er gemeint hat.

‣Andreas•⚖ 14:40, 26. Mär. 2015 (CET)

Das erklärt also wohl, warum es ein Programm gibt, das schafft, auf meiner HDD Ordner zu erstellen, die dann nicht im Windows Explorer auf eine andere Partition kopiert werden können. Ich weiß schon lange, das der Explorer dieses 260-Zeichen-Limit hat, aber ich wusste bisher nicht, wie dieses Programm es umgehen kann... --MrBurns (Diskussion) 18:37, 26. Mär. 2015 (CET)

LFN (Long File Name)

Im Artikel findet sich in der aktuellen Fassung ein Lückenhaft-Baustein mit dem Inhalt „Erläuterung des LFN-Systems (Long File Name. Ab wann sind für Dateinamenserweiterungen mehr als 3 Zeichen möglich und wie lang kann eine Dateinamenserweiterung heute maximal sein.“

Ich denke, dass dies aber kein Problem des Artikels Dateiname sein kann, ja noch nicht einmal eines des Artikels Dateinamenserweiterung. Da LFN eine Besonderheit des FAT-Dateisystems ist (VFAT, um genau zu sein), gehört es auch dort hin, und nicht hier hin. Denn im vorliegenden Dateiname-Artikel sind die maximalen Größen (etwa 8+3 bei FAT) gelistet. Mehr würde den Rahmen sprengen.

Gibt es noch andere Meinungen dazu? Sonst würde ich den Lückenhaft-Baustein gerne in den nächsten Tagen entfernen…

‣Andreas•⚖ 11:36, 12. Jun. 2016 (CEST)

Ich stimme zu, der Lückenhaft-Baustein sollte hier raus. -- Gerd Fahrenhorst (Diskussion) 12:55, 12. Jun. 2016 (CEST)

Ebenfalls Zustimmung. Habe den Baustein entfernt. Grüße, --Schotterebene (Diskussion) 13:05, 12. Jun. 2016 (CEST)

Danke für die Erledigung. ‣Andreas•⚖ 16:35, 12. Jun. 2016 (CEST)

Betriebssystem vs. Dateisystem (z.B. case-sensitivity)

Dateisysteme und Betriebssysteme sind zwei unterschiedliche Dinge, obwohl es natürlich auch klar ist, dass jedes Betriebssystem sein eigenes, speziell angepasstes, Dateisystem hervorgebracht hat. Aber man kann ja auch ein Dateisystem, das ursprünglich für ein anderes Betriebssystem ersonnen wurde, verwenden...

Beispiel Case sensitivity: Es ist nicht richtig, dass dies immer auf Dateisystemebene geschieht oder dort geschehen muss. Vielmehr ist es eine Kombination aus verwendetem Betriebssystem und verwendetem Dateisystem.

Ein Beispiel: verwendet man ein FAT-Dateisystem auf einem Unix oder Unix-artigen Betriebssystem, so werden die im Dateisystem nur in Großbuchstaben gespeicherten 8.3-Namen in Kleinbuchstaben umgewandelt, sind als solche jedoch case-sensitiv. Konkret bedeutet das z.B. dass FILENAME.EXT unter MS-DOS, dort case-insensitiv, unter Unix filename.ext heißt und case-sensitiv als FILENAME.EXT nicht erkannt wird.

Ein anderes Beispiel ist die Nutzung von NTFS auf Windows und auf Unix: hier ist – auf der Betriebssystem-Ebene (API-Level) – Windows ebenso case-insensitiv, Linux und andere Unices sind jedoch case-sensitiv. Glücklicherweise speichert NTFS – Dateisystem-Ebene – die Dateinamen inklusive Groß-/Kleinschreibung, sodass dies gut funktioniert. Interssant wird es, wenn man unter Linux "Langer-Dateiname.Erweiterung" und "langer-dateiname.erweiterung" anlegt – zwei verschiedene Dateinamen, dann aber unter Windows versucht, diese zu öffnen. Schreibt man den Dateinamen genau so, wie er gespeichert ist, öffnet man normalerweise die richtige Datei. Gibt man einen anderen, nicht existenten Namen an, macht das API aber vermutlich eine der beiden existierenden Dateien auf, man weiß aber nicht, welche. ("Lange-Dateiname.erweiterung" könnte sowohl "Langer-Dateiname.Erweiterung" als auch "langer-dateiname.erweiterung" öffnen...)

Siehe auch:

• https://superuser.com/questions/364057/why-is-ntfs-case-sensitive
• https://stackoverflow.com/questions/33998669/windows-ntfs-and-case-sensitivity

Bei HFS+ ist es noch etwas komplizierter, da die Normalisierung der Dateinamen hier nicht auf API-Level sondern auf Dateisystem-Treiber-Ebene passiert. Und, von HFS+ gibt es beide Varianten: case-sensitive und case-insensitive, die jedoch ein Dateisystem-Feature darstellen (da es ja eine Funktion des Dateisystems, nicht des Betriebssystems, ist). Dennoch hängt es zusätzlich vom Betriebssystem ab, wie es damit umgeht – oder stellt zumindest eine Möglichkeit dar.

@Filzstift: Das betrifft vorallem deine Änderungen, beginnend mit dieser...

Neben der Case-sensitivity betrifft das natürlich auch die Zugriffsrechte, die Zeitstempel, die alternativen Datenströme und so weiter...

Gruß, ‣Andreas•⚖ 16:16, 2. Dez. 2020 (CET)

Du hast das jetzt gerade recht ausführlich beschrieben und ich lernte da sogar was. Könnte das nicht in diesem Sinne umseitig reinkommen? Ein Punkt evtl. noch zur Ergänzung: M.W. gab es mit Windows 10, 1803 oder 1809 gewisse Anpassungen, nach der NTFS auf Verzeichnisebene bestimmt werden kann, ob Dateinamen dort case sensistive oder insensitive sind [2]. So wie das vorher im Artikel war, das war mir zu plakativ gewesen: Windows: insensistive, Unix: sensitive (dabei ist Linux kein Unix und macOS weicht aus historischen Gründen ab, und schlussendlich kommt das ja eben auf das Dateisystem an - neben der API, die API ist auch wichtig, da hast du recht). --Filzstift (Diskussion) 20:56, 2. Dez. 2020 (CET)

Ich hab mal einen Versuch unternommen, das einzuarbeiten. Aber wie tief in die Materie soll man da einsteigen?

Genaugenommen sind URLs, Internetadressen, auch Pfade auf Dateinamen, Webseiten auf einem Server, und entsprechen damit den Dateinamen der auf dem adressierten Server gespeichen Dateien, auf den dort genutzten Dateisystemen. URLs sind jedoch case-insensitiv, obwohl WWW-Server meist Unix-Server sind.

Die Implementierung von erweiterten Zeitstempeln, die z.B. auf älteren Dateisystem wie FAT fehlen (dort gibt es nur eine einzige Erstellungszeit, aber keine heute übliche Zugriffs- und Modifikationszeitstempel), und die Implementierung der Zugriffsrechte auf Dateisystemen anderer Betriebssysteme fehlt auch.

In der Kürze liegt die Würze, aber ich konnte es einfach nicht weiter kürzen ohne das alles wieder - im Endeffekt - falsch dasteht.

Ich halte dennoch den jetzt von mir verfassten Text für zu umfangreich. Was denkst du?

‣Andreas•⚖ 21:54, 2. Dez. 2020 (CET)

Einen ganz riesigen Dank für deine Überarbeitungen! Das liest sich jetzt viel besser, sachlich gibt es da auf dem ersten Blick nichts mehr zu bemängeln. Stimmt, es wirkt jetzt etwas überfracht. Eine Idee wäre, auch im Hinblick auf erweiterte Zeitstempel usw., einige Infos in den Artikel Dateisystem zu überführen oder in einen neuen Artikel, der schwerpunktmässig die "Metadaten" einer Datei behandelt (im FAT beispielsweise einen Eintrag in einem File allocation table, bestehend aus 11 Zeichen, Zeitstempel, Grösse, Attribute, Startcluster etc.). Gross-/Kleinschreibung hat noch mit dem Lemmagegenstand zu tun, der Rest weniger. --Filzstift (Diskussion) 21:04, 4. Dez. 2020 (CET)

Ich habe es gekürzt. Im Artikel case sensitivity stehen weitere Details, aber der Artikel Dateisystem reflektiert diese Informationen derzeit noch überhaupt nicht... ‣Andreas•⚖ 23:07, 4. Dez. 2020 (CET)