Viele Betriebssysteme schliessen bestimmte Dateinamen oder Dateinamensbestandteile rigoros aus. Das gibt zum einen oft Rueckschluesse auf die Herkuft eines Betriebssystems; zum anderen ist es ein Fall, auf den Systeme vielleicht nicht vorbereitet sind -- zumindest dann, wenn sie per Netzwerk miteinander verbunden werden. Und damit kann man ein bisschen spielen.

Einfuehrung

Mit einer einfachen Ansage unterbindet Windows, dass bestimmte Zeichen in Dateinamen auftauchen:

Windows verbietet die Zeichen \/:*?"<>| in Dateinamen.

Das ist so weit auch ganz elegant geloest, der Nutzer kann diese Dateinamen nicht eingeben. Aber auf anderen Betriebssystemen kann ich solche Dateinamen verwenden. Zum Beispiel kann ich eine Datei mit entsprechend "unsittlichem" Dateinamen auf einem FreeBSD anlegen:
[ad001@glas ~/filenametest]$ touch this-is-a\\nice-file
[ad001@glas ~/filenametest]$ touch contains-a-\*
[ad001@glas ~/filenametest]$ touch contains-a-\:
[ad001@glas ~/filenametest]$ ls
contains-a-*            contains-a-:            this-is-a\nice-file
Nun kann man dieses Verzeichnis via Samba von einem Windows aus mounten und sieht das hier:

Darstellung von unzulaessigen Dateinamen im Windows Explorer.

Das Ganze geht uebrigens auch mit anderen, weniger erwarteten Dateinamen:


Auch die Dateinamen nul, lpt1, com1..com9 sind unzulaessig.

Interessant ist hier die Fehlermeldung -- sie deutet ein wenig in die richtige Richtung. Diese Dateinamen waren unter MS-DOS fuer IO mit Devices (oder nichts) reserviert und sind es bis heute geblieben. Spannend sind sie besonders beim Testen von Anwendungen, wenn Pfade erst sehr spaet geprueft werden -- und dann mit dieser weniger erwarteten Fehlermeldung scheitern. Insbesondere, weil diese Dateinamen ja komplett harmlos aussehen und auch als Teil von Pfaden auftreten und diese z.B. in der Form C:\nul eigentlich valide aussehen. Nur eben nicht valide sind.

Von Samba und Scopes

Einen Schritt weitergedacht: Wie kommt es zu diesen merkwuerdigen Alias-Dateinamen? Irgendwo wird es eine Mapping-Tabelle geben, die dem Originaldateinamen den Alias zulost. Schauen wir doch mal, auf welcher Seite. Hierfuer und fuer die folgenden Beispiele soll die Datei nul.txt dienen.

[ad001@glas ~/filenametest/newfolder]$ touch nul.txt
[ad001@glas ~/filenametest/newfolder]$ ls
nul.txt
Um der Frage, wer da uebersetzt einen Schritt naeher zu kommen, kann man ja mal mit dem guten alten smbclient nachschauen, was der Samba-Server so erzaehlt:
smb: \filenametest\newfolder\> ls
  .                                   D        0  Fri Oct  5 17:23:10 2012
  ..                                  D        0  Fri Oct  5 17:22:52 2012
  NDH6SA~M.TXT                                 0  Fri Oct  5 17:38:09 2012

                63960 blocks of size 16777216. 20320 blocks available

Also entsteht die Magie ganz offensichtlich nicht auf Windows- sondern auf Samba-Seite (wie langweilig!). Damit spielen kann man aber trotzdem. Die Uebersetzungstable scheint naemlich bezogen auf Verzeichnisse keine Scopes zu kennen:
[ad001@glas ~/filenametest/newfolder]$ touch nul.txt
[ad001@glas ~/filenametest/newfolder]$ ls
nul.txt
Ausgangslage: Im Verzeichnis existiert eine Datei nul.txt -- die unter Windows den klangvollen Namen NDH6SA~M.txt traegt.
[ad001@glas ~/filenametest/newfolder]$ mkdir folder
[ad001@glas ~/filenametest/newfolder]$ ls
folder  nul.txt
Es wird ein neues Verzeichnis angelegt. Dass dies auf dem Unix geschieht ist nicht relevant.
In diesem neuen Verzeichnis wird jetzt eine neue Datei erstellt. Ihr wird der Dateiname NDH6SA~M.txt gegeben.
[ad001@glas ~/filenametest/newfolder]$ cd folder/
[ad001@glas ~/filenametest/newfolder/folder]$ ls
nul.TXT
Und -- tadaa -- die Datei wird auf dem entfernten Dateisystem unter einem anderen --falschen!-- Dateinamen abgelegt.

Kollision zwischen "echtem" und "gemapptem" Dateinamen

Und nun kann man es mal krachen lassen: Was passiert, wenn es den "virtuellen" Dateinamen denn schon gibt?

[ad001@glas ~/filenametest/newfolder]$ touch NDH6SA~M.txt
[ad001@glas ~/filenametest/newfolder]$ ls
NDH6SA~M.txt    folder          nul.txt
Fast... nur die Erweiterung fehlt noch. Das kann man aber nachholen..
[ad001@glas ~/filenametest/newfolder]$ mv NDH6SA~M.txt NDH6SA~M.TXT
[ad001@glas ~/filenametest/newfolder]$ ls
NDH6SA~M.TXT    folder          nul.txt
Tadaa! Zwei Dateien mit identischem Dateinamen in einem Verzeichnis.
Nun kann man eine der beiden Dateien oeffnen und etwas eingeben. Die Daten landeten in allen Tests in der Datei deren Name nicht gemappt wurde. Deren Inhalt wurde auch in allen Tests beim Oeffnen beider scheinbarer Dateien angezeigt -- in keinem Fall wurde die nul.txt geoeffnet.

Dateien werden angezeigt, koennen aber nicht geoeffnet werden

Windows verbietet die Dateinamen com1..com9 -- gemappt werden aber nur com1..com4. Dateien com5..com9 werden angezeigt:

Diese Dateinamen koennen unter Windows nicht erstellt werden -- wohl aber werden sie im Listing angezeigt.

Versucht man nun aber diese Dateien zu oeffnen, so gibt es einen (merkwuerdigen) Fehler:

Diese Dateinamen koennen unter Windows nicht erstellt werden -- wohl aber werden sie im Listing angezeigt.

Hier bietet sich eine herrliche Moeglichkeit, Windows-Nutzer zu aergern. Die Datei ist da, die Leserechte stimmen -- aber trotzdem kann die Datei nicht gelesen werden :)

Liste der Standard-Ersatznamen

Zum Schluss hier noch die Liste der vorgefundenen Aliasnamen (die Vergabe erfolgt Case-Insensitive):

Realname (Unix) Mappingname (Windows)
nul NDH6SA~M
lpt1 LK8OWQ~K
lpt2 LK8OWQ~N
lpt3 LK8OWQ~M
com1 CR23RR~9
com2 CR23RR~A
com3 CR23RR~B
com4 CR23RR~4
Virtuelle Dateinamen auf der Basis von "unzulaessigen" Zeichen unter Windows scheinen zufaellig; auch mit diesen laesst sich allerdings das Phaenomen eines verzeichnisglobalen Scopes beobachten.

Ausblick und further reading

Man kann das ganze natuerlich noch weiterdenken: Sofort stellt sich die Frage, ob sich dieses Verhalten exploiten laesst -- zum Beispiel, um Dateien zu ueberschreiben, die man ansonsten nicht ueberschreiben duerfte? Was passiert, wenn da ein '\0' enthalten ist? So viele Fragen, so weig Zeit. Und wie reagieren die Windows-Nutzer, wenn man eine Datei mit Namen nul in ein SVN-Repo einschleust?
Mit Dateinamen wird schon laenger gespielt... das Hypftier hat sich da schon 2006 drueber ausgelassen: http://www.informatik.uni-rostock.de/~jr252/filenames.xml.

Stichworte:


Impressum