Gibt es einen POSIX-Pfadnamen, der keine Datei benennen kann?

2064
Charles Stewart

Gibt es legale Pfade in POSIX, die nicht mit einer regulären oder unregelmäßigen Datei verknüpft werden können? Das heißt, für was test -e "$LEGITIMATEPOSIXPATHNAME"kann es nicht gelingen?

Erläuterung Nr. 1: Pfadnamen

Mit "legale Pfade in POSIX" meine ich diejenigen, die laut POSIX zulässig sind, nicht solche, die POSIX nicht ausdrücklich verbietet. Ich habe das nachgeschlagen, und die POSIX-Spezifikation nennt sie Zeichenketten, die:

  1. Verwenden Sie nur Zeichen aus dem tragbaren Dateinamen-Zeichensatz [a-zA-Z0-9._-](vgl. Http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html#tag_03_276 );
  2. Beginnen Sie nicht mit -; und
  3. Länge zwischen 1 und NAME_MAX, eine für POSIX nicht angegebene Zahl, die nicht unter 14 liegt.

POSIX erlaubt auch, dass Dateisysteme wahrscheinlich entspannter sind als dies, aber es verbietet den Zeichen NUL und /dem Auftauchen in Dateinamen. Beachten Sie, dass ein solch paradigmatischer UNIX-Dateiname lost+foundnicht FPF ist, gemäß dieser Definition. Es gibt eine weitere Konstante PATH_MAX, deren Verwendung keiner weiteren Erklärung bedarf.

Die ideale Antwort wird FPFs verwenden, aber ich bin an allen Beispielen mit Dateinamen interessiert, die POSIX nicht ausdrücklich verbietet.

Klarstellung Nr. 2: Unmöglichkeit

Offensichtlich können Pfadnamen normalerweise an eine Datei gebunden sein. Die UNIX-Semantik sagt jedoch aus, dass es spezielle Stellen gibt, an denen normalerweise keine beliebigen Dateien erstellt werden könnten, wie im /devVerzeichnis. Sind solche besonderen Orte in POSIX festgelegt? Das ist, was die Frage danach stellt.

4
Hmmm, ich habe mich gefragt, ob dieser Titel nicht aussagekräftiger sein könnte, aber was immer ich auch finde, scheint einen Widerspruch in Bezug auf ... Arjan vor 14 Jahren 4
viel besserer Titel, danke. quack quixote vor 14 Jahren 0
Nur eine Notiz ... es ist nicht \ es ist /. In Unix ist ein feines Zeichen in einer Datei. / user / chuck / tom \ mary Der Dateiname = tom \ mary. DrFloyd5 vor 14 Jahren 0
@DrFloyd: Richtig. Fest. Charles Stewart vor 14 Jahren 0
Ich mag diese Frage. Es erinnert mich daran, dass "Der Mouse" beim Wechsel von VMS zu UNIX ärgerlich war, weil er keine Möglichkeit fand, einen Dateinamen mit einem Schrägstrich oder einer Null zu erstellen - wobei der Schrägstrich Teil des Dateinamens in einem Verzeichnis war. anstatt ein Trennzeichen zwischen Verzeichnis und etwas im Verzeichnis. // Die Standard-POSIX-APIs erzeugen bei solchen Dateinamen keinen Fehler. Sie interpretieren die eingebetteten Sonderzeichen einfach als pfadseparierte Zeichenfolgen oder als Zeichenfolgenabschlusszeichen. Krazy Glew vor 8 Jahren 1

5 Antworten auf die Frage

3
Anonymous

Das Testen auf einen Dateinamen mit dem Nullzeichen sollte immer fehlschlagen.

POSIX behält '/' und null von Dateinamen. Dies ist sinnvoll: Eines ist das Verzeichnistrennzeichen und eines ist ein Zeichenfolgenabschlusszeichen. Um diesen Punkt zu unterstützen, sagt Wikipedia, dass ext2, ext3 und ext4 alle Bytes in Dateinamen mit Ausnahme von null und des Schrägstrichs zulassen. Ob im POSIX-Kompatibilitätsmodus oder nicht, NTFS lässt etwas darüber hinaus. und FAT-Varianten verbieten auch null. Theoretisch hängt es wirklich vom Dateisystem ab. Aber ich würde nicht den Atem anhalten und versuchen, einen Fall zu finden, in dem null den Dateinamen gefunden hat.

+1 für eine Antwort, die mich etwas nachschlagen ließ. POSIX verbietet "/" und NUL in Dateinamen. Vgl. meine Fragen Postscript. Charles Stewart vor 14 Jahren 0
3
harrymc

Da die letzte Frage ist, ob es spezielle Orte gibt, an denen normalerweise keine Datei vorhanden sein könnte, wie im Verzeichnis / dev in POSIX angegeben, lautet der Wert JA .

Die vollständige Liste der vordefinierten Dateien und Verzeichnisse finden Sie in Kapitel 10, POSIX-Verzeichnisstruktur und -Geräte der IEEE Open Group-Basisspezifikation Ausgabe 6 :

Die folgenden Verzeichnisse müssen auf konformen Systemen vorhanden sein und konforme Anwendungen dürfen diese nur wie beschrieben verwenden. Streng konforme Anwendungen dürfen nicht die Fähigkeit annehmen, Dateien in einem dieser Verzeichnisse anzulegen, es sei denn, dies ist nachstehend angegeben.

/
Das Wurzelverzeichnis.
/ dev
Enthält / dev / console, / dev / null und / dev / tty (siehe unten).

Das folgende Verzeichnis muss auf konformen Systemen vorhanden sein und wie beschrieben verwendet werden:

/ tmp
Ein Verzeichnis, das für Anwendungen zur Verfügung gestellt wird, in denen temporäre Dateien erstellt werden müssen. Anwendungen dürfen Dateien in diesem Verzeichnis erstellen, dürfen jedoch nicht davon ausgehen, dass diese Dateien zwischen Aufrufen der Anwendung erhalten bleiben.

Die folgenden Dateien müssen auf konformen Systemen vorhanden sein und sowohl lesbar als auch beschreibbar sein:

/ dev / null
Eine unendliche Datenquelle und Datensenke. In / dev / null geschriebene Daten werden verworfen. Lesen von / dev / null gibt immer das Dateiende (EOF) zurück.
/ dev / tty
In jedem Prozess ein Synonym für das steuernde Terminal, das der Prozessgruppe dieses Prozesses zugeordnet ist, sofern vorhanden. Dies ist nützlich für Programme oder Shell-Prozeduren, die sicher sein wollen, dass Nachrichten in das Terminal geschrieben oder von diesem gelesen werden, unabhängig davon, wie die Ausgabe umgeleitet wurde. Es kann auch für Anwendungen verwendet werden, die zur Ausgabe den Namen einer Datei verlangen, wenn eine typisierte Ausgabe gewünscht wird und es schwierig ist, herauszufinden, welches Terminal gerade verwendet wird.

Die folgenden Dateien müssen auf konformen Systemen vorhanden sein und müssen weder lesbar noch schreibbar sein:

/ dev / console
Die Datei / dev / console ist ein generischer Name, der der Systemkonsole gegeben wird (siehe Systemkonsole). Sie ist normalerweise mit einer implementierungsdefinierten Spezialdatei verknüpft. Sie muss eine Schnittstelle zur Systemkonsole bereitstellen, die den Anforderungen des Volumes "Base Definitions" von IEEE Std 1003.1-2001, Kapitel 11, General Terminal Interface (Allgemeine Terminalschnittstelle) entspricht.

Ich gehe davon aus, dass der Begriff "Dateien" auch Verzeichnisse umfasst. In einem Beispiel kann ein POSIX-Programm auch nicht davon ausgehen, dass es ein Verzeichnis mit dem Namen "unmöglich" erstellen kann. Die verwendete Terminologie ist etwas verwirrend, und ich nehme an, die Autoren hätten nicht gedacht, dass / dev Verzeichnisse enthalten könnte. harrymc vor 14 Jahren 0
`/ dev` kann Verzeichnisse enthalten und enthält in der Regel Verzeichnisse: SunOS hat seit Ewigkeiten ein fsfs unter` / dev / fd` eingehängt und von den meisten modernen UNIXes kopiert. POSIX verbietet jedoch, dass eine Datei sowohl ein Sonderzeichen als auch ein Verzeichnis ist. Daher kann unter `/ dev / tty` nichts enthalten sein. So gewählt: Ich habe meine Antwort. Charles Stewart vor 14 Jahren 0
2
Demi

/dev/null/impossiblekann nicht existieren Dies liegt daran, dass /dev/nulles sich um eine Datei handeln muss und daher kein Verzeichnis sein kann.

Gleiches für /dev/tty/impossibleund/dev/console/impossible

1
grawity

"Legaler Pfad in POSIX" bedeutet bereits, dass er auf ein Dateisystemobjekt (Datei, Verzeichnis, Symlink usw.) verweisen kann.

Beim zweiten Gedanken haben einige Dateisysteme (wie FAT) Einschränkungen für zulässige Zeichen in Dateinamen. Also in meinem Computer, ~/fs/phone/This:is*a?file|name.txtwürde vom vfatDateisystemtreiber abgelehnt .

Um die zweite Frage zu beantworten, test -e "$LEGITIMATEPOSIXPATHNAME"schlagen Sie fehl, wenn die Datei offensichtlich nicht vorhanden ist.

Hehe, +1 für den letzten Absatz. Ich denke, auf jede Frage gibt es eine Antwort. :-) Arjan vor 14 Jahren 0
s / fail / kann nicht erfolgreich sein / Charles Stewart vor 14 Jahren 0
Ich bin mit keinem * nix vertraut, wo `/ dev / fd / this-is-not-a-file` eine Datei sein könnte, aber IIUC, POSIX sagt nicht, dass es keine Datei sein könnte. Ein legaler Pfad in POSIX bedeutet also nicht, dass ein POSIX-kompatibles Betriebssystem eine Datei dort erstellen muss. Charles Stewart vor 14 Jahren 1
-1: Der Punkt der Frage wird völlig verfehlt. Charles Stewart vor 14 Jahren 0
@Charles, es kommt mir irgendwie seltsam vor, dass Sie downvoting sind, während ich glaube, dass Ihre Frage überhaupt nicht klar war. (Und * hat * noch einen sehr schlechten Titel, was überhaupt keine Frage ist - http://superuser.com/faq) Arjan vor 14 Jahren 0
@Arjan: Titel geändert. Da die Leute es falsch verstehen, müssen Sie wohl recht haben, dass es nicht klar ist, aber ich sehe nicht, wo das Problem liegt. Es hat die Form "Gibt es ein X, das Y ist", wo die Xs bekannt sind und das Y genau definiert ist. Charles Stewart vor 14 Jahren 0
0
harrymc

Der Test schlägt fehl, wenn der Dateiname die Einschränkungen der lokalen Implementierung von POSIX durchbricht.

Jedes vorhandene Dateisystem geht von Annahmen hinsichtlich der maximalen Länge, Verzeichnisrekursionsgrenzen und mehr aus. Ein POSIX-Name, der für ein Betriebssystem zulässig ist, ist für ein anderes Betriebssystem möglicherweise nicht zulässig.

Daher ist meine Antwort auf die Frage "Ja":
Selbst Namen, die auf einem POSIX-System getestet wurden, können aufgrund von Implementierungseinschränkungen von einem anderen abgelehnt werden.

Jeder von POSIX als legal angegebene Pfadname wird per Definition für alle POSIX-kompatiblen Dateisysteme akzeptiert. Es sind diese, die mich interessieren. Charles Stewart vor 14 Jahren 0
Nun, NAME_MAX und PATH_MAX sind implementierungsabhängig. Ich denke, dass Sie sich widersprechen, wenn Sie (1) nach unerreichbaren POSIX-Dateinamen fragen und (2) gleichzeitig auf allen POSIX-kompatiblen Systemen akzeptiert werden. Definitionsgemäß können akzeptable Dateinamen nicht unerreichbar sein, und der kleinste gemeinsame Nenner aller POSIX-Systeme ist auf allen Systemen immer erreichbar. harrymc vor 14 Jahren 0
Aha! Nein, ich möchte, dass Pfadnamen funktionieren, mit der Ausnahme, dass andere Annahmen in POSIX verhindern, dass die Dateien vorhanden sind Charles Stewart vor 14 Jahren 0

Verwandte Probleme