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)