Frage zum Wiki-Artikel „Dateiorganisation“

[MacRudi]

Weiß nicht, ob diese Vertiefung Sinn macht, nur ein Angebot:

Genauer gesagt, ist die mögliche Namensvergabe abhängig vom Dateisystem. Bei lokalen Dateien ist es das Dateisystem auf dem eigenen Rechner, bei Dateien auf dem Server dessen Dateisystem. Die Tendenz bei Servern dürfte Richtung groß-/kleinschreib-sensitiv gehen. Auf dem Server können dann die Dateien test.gif, test.GIF und Test.gif nebeneinander existieren. Beim Runterladen oder in einem Backup kann es auf dem lokalen Rechner zu Problemen kommen, wenn dieses Dateisystem nicht sensitiv ist.

Liegt auf dem Server die Datei http://domain.xy/test.gif, dann wird ein Link auf http://domain.xy/Test.gif sie bei Sensitivität nicht finden. Es sei denn, der Hosting-Provider bietet den Service, dass auch Dateien, die sich nur in der Groß-/Kleinschreibung unterscheiden, gefunden werden. Das ist auch gern damit verbunden, dass sogar Dateien gefunden werden, die einen anderen Buchstaben enthalten oder ein Buchstabe fehlt. Zieht man dann zu einem anderen Hosting-Provider ohne diesen Komfort um, wird man Ungenauigkeiten korrigieren müssen. Man sollte also damit nicht lachs umgehen. Schließlich ist es eigentlich für Webseitenbesucher gedacht, die eine Seite angezeigt bekommen sollen, selbst wenn sie die Adresse nicht ganz richtig eingegeben haben.

[Rolf B]

Hallo MacRudi,

ob ein Server groß-/kleinsensitiv ist, hängt vom verwendeten Filesystem ab. Und ja: das ist ein ÄRGERNIS.

Linuxe sind sensitiv, Windosen nicht. Es sei denn, man verwendet ein Windows mit dem Windows-Subsystem für Linux und aktiviert dann für bestimmte Order die case-sensitivity. Yep, das gibt's! Ein case-insensitives Linux habe ich noch nicht gesehen. Einen Webserver, der unter Linux Dateien case-insensitive als Komfort-Funktion sucht, allerdings auch nicht - ist das ein Apache-Feature, das man einschalten kann? Oder hext man sowas per Rewrite-Rule zurecht?

Der Rat für einen Webseitenbetreiber sollte meiner Meinung nach sein: Mach alles klein. Denn andernfalls ist einem viel zu schnell das test.GIF vs test.gif Szenario unterlaufen.

Beim Upload von einem Windows-Gerät ist das extra lästig, weil dort sehr gerne mal eine GIF oder JPG Datei herumfliegt, die eigentlich eine gif oder jpg Datei sein sollte. Und unter Windows kann man sie dann nichtmal in einem Zug umbenennen, weil er wegen der case-insensitivity meint, dass man nichts geändert habe und darum nichts zu tun sei 😟

Rolf

[Matthias Scharwies]

Guten Morgen,

das bezieht sich ja alles auf das Kapitel: Konventionen_für_Dateinamen

Meiner Meinung nach ist das Problem dort gut erklärt.

Auch die Empfehlung am Ende des Abschnittes finde ich gut:

Empfehlung: Verwenden Sie …

• konsequente Kleinschreibung für Dateinamen und -endungen, um Missverständnissen vorzubeugen.
• Dateinamen nur bis zu 256 Zeichen Länge, auch wenn einige Systeme längere Namen erlauben.
• nach Möglichkeit keine Leerzeichen, Umlaute oder ß in den Dateinamen, obwohl dies dank URL-Codierung und UTF-8 nicht mehr so problematisch ist. Für ein internationales, nicht-deutschsprachiges Publikum und zum Abtippen bestimmter URLs sollten aber lieber alphanumerische ASCII-Zeichen ohne Großbuchstaben verwendet werden.
• als weiteres Sonderzeichen nur den Unterstrich "_". Andere Satzzeichen können in bestimmten Fällen problematisch sein.
  • Fragezeichen "?" und Sternzeichen "*" sollten Sie auf jeden Fall vermeiden, da diese Zeichen bei fast allen Systemen eine besondere Bedeutung haben.
  • Auch auf Leerzeichen sollten Sie unbedingt verzichten. (Diese werden z. B. von der Mediawiki-Software in Unterstriche umgewandelt.)

Was würdet ihr da ändern /ergänzen wollen?

Herzliche Grüße

Matthias Scharwies

[Gunnar Bittersmann]

@@Matthias Scharwies

Empfehlung: Verwenden Sie … nach Möglichkeit keine Leerzeichen, Umlaute oder ß in den Dateinamen, obwohl dies dank URL-Codierung und UTF-8 nicht mehr so problematisch ist.

Fun fact: Ich verwende Umlaute in Dateinamen, bspw. https://gunnarbittersmann.de/songs/zehn-kleine-weltraumfähren.

Aber entweder ist die Normalisierung auf meinem lokalen System (macOS) und auf dem Server eine andere oder das FTP-Programm macht Murks. Jedenfalls: wenn ich zehn-kleine-weltraumfähren.html initial auf den Webserver schiebe, kann ich die Ressource nicht aufrufen.

Ich muss die Datei auf dem Server in zehn-kleine-weltraumfähren.html umbenennen (also gleichen Dateinamen – im Gegensatz zu Windows-Systemen geht das), dann stimmt die Normalisierung und die Ressource ist aufrufbar. Spätere Aktualisierungen sind kein Problem: Datei übertragen, Normalisierung stimmt immer noch.

Trotzdem PITA^[1]. Ich bin davon abgekommen, Umlaute in Dateinamen zu verwenden. Bin auch am Überlegen, bestehende Dateien umzubenennen. (Und Weiterleitungen einzurichten – Cool links don’t change.)

Kwakoni Yiquan

---

1. pain in the ass ↩︎

[Auge]

Hallo

Was würdet ihr da ändern /ergänzen wollen?

…

• als weiteres Sonderzeichen nur den Unterstrich "_". Andere Satzzeichen können in bestimmten Fällen problematisch sein.

Früher™️ habe auch ich den Unterstrich benutzt, bin aber mittlerweile davon abgekommen und benutze statt seiner den Bindestrich "-". Das spart mir und Nutzern, die in die Verlegenheit kommen sollten, einen Dateinamen, Pfad oder eine URL abzutippen (warum auch immer), einen Tastendruck per Zeichen. Außerdem ist der Bindestrich mindestens genauso unproblematisch, wie sein Mitbewohner.

Ich finde die Formulierung daher etwas irreführend, da sie durch die Gegenüberstellung von Unterstrich und „andere[n] Satzzeichen“ diesen nach meinem Empfinden über Gebühr als „das“ unproblematische Satzzeichen hervorhebt. Das wird mMn in Bezug auf andere Satzzeichen durch die Formulierung „in bestimmten Fällen“ auch nicht mehr rausgerissen.

• Fragezeichen "?" und Sternzeichen "*" sollten Sie auf jeden Fall vermeiden, da diese Zeichen bei fast allen Systemen eine besondere Bedeutung haben.

Ein weiterer Kandidat ist der Doppelpunkt ":", auch wenn mir der eher in den Dateinamen von automatisch generierten Dateien mit einen Zeitstempel im Namen, begegnet ist, als in händisch angelegten Dateien. Zumindest können solche Dateinamen verwirren, nachdem man sie per FTP von einen Unixoiden auf ein Windows-System heruntergeladen hat.

Tschö, Auge

[Gunnar Bittersmann]

@@Auge

Früher™️ habe auch ich den Unterstrich benutzt, bin aber mittlerweile davon abgekommen und benutze statt seiner den Bindestrich "-". Das spart mir und Nutzern, die in die Verlegenheit kommen sollten, einen Dateinamen, Pfad oder eine URL abzutippen (warum auch immer), einen Tastendruck per Zeichen.

Hinzu kommt: Wenn ein URL unterstrichen wird (bspw. wenn ein URL als Linktitel verwendet wird – sollte man nicht tun, kann aber vorkommen), dann ist der Unterstrich kaum vom Leerzeichen zu unterscheiden.

Ein weiterer Kandidat ist

… der Schrägstrich. Da Trennzeichen im Pfad, sollte er in Dateinamen besser nicht vorkommen.

Kwakoni Yiquan

[Rolf B]

Hallo Gunnar,

Schrägstrich … sollte … in Dateinamen besser nicht vorkommen

Wieso?

Damit kommt man prima zurecht.

Solange es U+2215 ist 😉

Rolf

[Auge]

Hallo

Früher™️ habe auch ich den Unterstrich benutzt, bin aber mittlerweile davon abgekommen und benutze statt seiner den Bindestrich "-". Das spart mir und Nutzern, die in die Verlegenheit kommen sollten, einen Dateinamen, Pfad oder eine URL abzutippen (warum auch immer), einen Tastendruck per Zeichen.

Hinzu kommt: Wenn ein URL unterstrichen wird (bspw. wenn ein URL als Linktitel verwendet wird – sollte man nicht tun, kann aber vorkommen), dann ist der Unterstrich kaum vom Leerzeichen zu unterscheiden.

Hmm, noch ein Argument gegen den Unterstrich.

Ein weiterer Kandidat ist

… der Schrägstrich. Da Trennzeichen im Pfad, sollte er in Dateinamen besser nicht vorkommen.

Ich kann jetzt die Situation in Linux nicht eruieren, weiß aber, dass das in Windows beide Schrägstriche (\ und /) betrifft, man dort solcherart Dateinamen aber auch gar nicht erst erzeugen kann. Aber die Fälle \, /, :, * und ? werden ja bereits im Wiki-Artikel im ersten Punkt der Liste im Abschnitt Konventionen für Dateinamen abgefrühstückt.

Auch die Umständlichkeit der manuellen Maskierung bestimmter Zeichen ^[1] wird dort thematisiert. Dass es da zusätzliche Fallstricke in bestimmten Betriebssystemen geben kann ^[2], kommt noch oben drauf, sei jetzt aber mal dahingestellt.

Tschö, Auge

---

1. Bei maschineller Erstellung von Links zu solchen Dateien wird die Maskierung ja hoffentlich automatisch vorgenommen. ↩︎

2. Ich vermute mal, dass dein im anderen Posting beschriebenes Umlautproblem die Spezialität von Apples OS ist, Umlaute sowohl als Zeichen als auch als Zeichenkombi von Buchstabe und Trema speichern zu können. ↩︎

[Robert B.]

Moin,

Ein weiterer Kandidat ist

… der Schrägstrich. Da Trennzeichen im Pfad, sollte er in Dateinamen besser nicht vorkommen.

Ich kann jetzt die Situation in Linux nicht eruieren, weiß aber, dass das in Windows beide Schrägstriche (\ und /) betrifft, man dort solcherart Dateinamen aber auch gar nicht erst erzeugen kann.

Unix-Dateisysteme verwenden den Schrägstrich als Pfadtrenner, das Zeichen kann dort also gar nicht Teil eines Dateinamens sein (ebenso das NULL-Byte, weil die API auf C-Strings basiert und dort dieses Byte das Ende der Zeichenkette darstellt). Unter macOS kann man scheinbar den Schrägstrich im Dateinamen verwenden, aber mit Hilfe des Terminals sieht man, dass dort tatsächlich ein Doppelpunkt verwendet wird, denn der Finder als Schrägstrich darstellt.

Viele Grüße
Robert

[Tabellenkalk]

Hallo,

• Dateinamen nur bis zu 256 Zeichen Länge, auch wenn einige Systeme längere Namen erlauben.

ist es nicht sogar so, dass Dateiname + Pfadname die 256 nicht überschreiten soll?

Gruß
Kalk

[Der Martin]

Hi,

• Dateinamen nur bis zu 256 Zeichen Länge, auch wenn einige Systeme längere Namen erlauben.

ist es nicht sogar so, dass Dateiname + Pfadname die 256 nicht überschreiten soll?

der Einwand irritiert mich - weil ich bisher der Meinung war, dass der Pfad ein Teil des Dateinamens ist.

Einen schönen Tag noch
 Martin

[Rolf B]

Hallo Martin,

weil ich bisher der Meinung war, dass der Pfad ein Teil des Dateinamens ist.

Plausibilitätscheck: wenn /foo/bar/baz.txt der Dateiname ist, was ist dann in deinem Wörterbuch das baz.txt?

Historycheck: RFC 114

Rolf

[Der Martin]

Hi,

weil ich bisher der Meinung war, dass der Pfad ein Teil des Dateinamens ist.

Plausibilitätscheck: wenn /foo/bar/baz.txt der Dateiname ist, was ist dann in deinem Wörterbuch das baz.txt?

Historycheck: RFC 114

"A named file is uniquely identified in a system by its file name and directory name."

Das ist für mich die Aussage, dass der Verzeichnisname ein Teil des Dateinamens ist.

Einen schönen Tag noch
 Martin

[Rolf B]

Hallo Martin,

für mich ist das die Aussage, dass eine Datei einen Dateinamen hat und der Verzeichnisname hinzu kommt, um sie eindeutig zu identifizieren. Das Kompositum ist dann der Pfadname.

RFC114 ist ziemlich alt, vielleicht gab's da noch keine hierarchischen Dateisysteme und deshalb sprechen sie vom Verzeichnisnamen. Zeitgemäß wäre hier sicherlich der Verzeichnispfad als eine durch / oder \ getrennte Liste von Verzeichnisnamen, die Dich vom Root zum korrekten Verzeichnis im Verzeichnisbaum leitet.

Rolf

[Gunnar Bittersmann]

@@Rolf B

Zeitgemäß wäre hier sicherlich der Verzeichnispfad als eine durch / oder \ getrennte Liste von Verzeichnisnamen

Das Zeichen \ kenne ich nur aus dem Emoticon \o/. Wofür sollte das noch gut sein? 😎

Kwakoni Yiquan

[Robert B.]

Moin Gunnar,

Zeitgemäß wäre hier sicherlich der Verzeichnispfad als eine durch / oder \ getrennte Liste von Verzeichnisnamen

Das Zeichen \ kenne ich nur aus dem Emoticon \o/. Wofür sollte das noch gut sein? 😎

für Escape-Sequenzen 😝

Viele Grüße
Robert

[Tabellenkalk]

Hallo,

da haben wir beide wohl einen Fehler drin: laut Wikipedia enthält der Pfadname sowohl die Verzeichnisse als auch den Dateinamen…

Gruß
Kalk