it-swarm.com.de

Warum enthält '/' '..'?

Es gibt kein Verzeichnis über /, also was ist der Sinn des .. drin?

24
EmmaV

Ein Sonderfall ist der Eintrag .. Im Stammverzeichnis.

Aus dem POSIX-Standard ( 4.13 Pfadnamenauflösung , wobei die Einträge . Und .. Jeweils als "Punkt" und "Punkt-Punkt" bezeichnet werden):

Der spezielle Dateinamenpunkt bezieht sich auf das vom Vorgänger angegebene Verzeichnis. Der spezielle Dateiname Punkt-Punkt bezieht sich auf das übergeordnete Verzeichnis des Vorgängerverzeichnisses. Als Sonderfall kann sich Punkt-Punkt im Stammverzeichnis auf das Stammverzeichnis selbst beziehen.

Die Begründung hat dies hinzuzufügen ( A.4.13 Pathname Resolution )

Worauf sich der Dateiname Punkt-Punkt relativ zum Stammverzeichnis bezieht, ist implementierungsdefiniert. In Version 7 bezieht er sich auf das Stammverzeichnis selbst; Dies ist das in POSIX.1-2017 erwähnte Verhalten. In einigen vernetzten Systemen wird die Konstruktion /../hostname/ Verwendet, um auf das Stammverzeichnis eines anderen Hosts zu verweisen, und POSIX.1 erlaubt dieses Verhalten.

Andere vernetzte Systeme verwenden das Konstrukt //hostname Für denselben Zweck. Das heißt, es wird eine doppelte Initiale <slash> verwendet. [...]

Kurz gesagt, der POSIX-Standard besagt, dass jedes Verzeichnis sowohl . Als auch .. Einträge haben sollte und dass der Verzeichniseintrag .. In / Verweisen kann in das Verzeichnis / selbst (beachten Sie das Wort "may" im ersten zitierten Text), aber es ermöglicht einer Implementierung auch, es auf etwas anderes verweisen zu lassen.

Bei den meisten gängigen Implementierungen von Dateisystemen wird /.. In / Aufgelöst.

32
Kusalananda

Kusalananda hat Ihnen bereits mitgeteilt, dass dies das im POSIX-Standard festgelegte Verhalten ist. die Geschichte von UNIX begann jedoch ernsthaft in den frühen 1970er Jahren. POSIX stammt erst aus der zweiten Hälfte der 1980er Jahre, volle anderthalb Jahrzehnte später. In der Praxis hat POSIX lediglich angegeben, was bereits getan wurde durch Implementierungen.

Vielmehr unterstützte UNIX schon sehr früh das Mounten von Dateisystemen auf verschiedenen Geräten in einer einzigen einheitlichen Verzeichnishierarchie. Tatsächlich hat jedes Dateisystem ein eigenes Stammverzeichnis. Das bei / gemountete Dateisystem ist in keiner Weise besonders speziell. (Sein Inhalt könnte sein, aber das Dateisystem selbst ist es nicht.)

Die Systemaufrufe sysmount und sysumount scheinen 1970-1971 in UNIX V1 eingeführt worden zu sein (V1 ist laut nix Tree at The Unix Heritage) von 1971-11 datiert Gesellschaft ). Sie sind in 1.s (Systemrufnummern 21 bzw. 22) definiert und in 7.s implementiert. (PDP7 UNIX, datiert 1970-01, scheint keinen offensichtlichen Vorfahren davon zu haben ).

Sie sehen wahrscheinlich, wohin das führt: Wenn any Dateisystem an any Position in der Hierarchie gemountet werden kann, um keine Sonderfälle zu haben, Jedes Verzeichnis, einschließlich des Stammverzeichnisses jedes Dateisystems, sollte einen Eintrag enthalten, der auf sein eigenes übergeordnetes Verzeichnis verweist. Auf der Festplatte ist der logische Ort, an dem auf den übergeordneten Verzeichniseintrag des Stammverzeichnisses eines Dateisystems verwiesen wird, das Stammverzeichnis des Dateisystems, da sich nichts "über" dem Stammverzeichnis des Dateisystems befindet. Das Konzept, etwas "über" dem Stammverzeichnis zu haben, kommt nur dann ins Spiel, wenn dieses Dateisystem an einem anderen Ort als dem Stamm der Hierarchie bereitgestellt wird.

Während des Mountens ist es möglich, den Zeiger "Elternverzeichnis" in der Speicherkopie des Stammverzeichnisses so umzuschreiben, dass er auf das übergeordnete Verzeichnis des Mountpunktverzeichnisses zeigt. Wenn es kein übergeordnetes Verzeichnis des Mountpunktverzeichnisses gibt (mit anderen Worten, das Dateisystem wird als / Bereitgestellt), lassen Sie dieses Datenelement einfach in Ruhe (da es wahrscheinlich nirgendwo anders sinnvoll ist, darauf zu verweisen sowieso) oder behandeln Sie es später separat (wie es wahrscheinlich für die in Kusalanandas Antwort erwähnten Fälle /../hostname/path und //hostname/path der Fall wäre).

Das resultierende Verhalten ist, dass in einem anderen Verzeichnis als /.. Auf das übergeordnete Verzeichnis dieses Verzeichnisses verweist, unabhängig davon, ob es sich um das Stammverzeichnis eines bestimmten Dateisystems oder um ein Unterverzeichnis (auf einer beliebigen Verschachtelungsebene) handelt ;; und in / zeigt .. zurück auf /. Ersteres fühlt sich natürlich an (.. Funktioniert immer auf die gleiche Weise und bewegt Sie einen Schritt in Richtung Stammverzeichnis), während letzteres, obwohl es etwas eigenwillig ist, zumindest offensichtlich nichts kaputt macht (es gibt wenig harm nicht weiter in Richtung Stammverzeichnis als in das Stammverzeichnis selbst gehen können). Zum Beispiel können Sie eine beliebige Anzahl von ../ Aushämmern und wissen, dass diese zumindest keinen Fehler verursachen, weil .. Irgendwann nicht mehr existiert .

17
a CVn

Es gibt ein Verzeichnis über /, / Selbst. Das übergeordnete Verzeichnis des Stammverzeichnisses ist selbst. cd .. Oder cd ../.. Im Stammverzeichnis sollten Sie an derselben Stelle belassen und keinen Fehler verursachen.

Beachten Sie, dass in einigen Dateisystemen weder . Noch .. Als tatsächliche Verzeichniseinträge vorhanden sein können. Sie werden möglicherweise einfach von der virtuellen Dateisystemschicht des Betriebssystems emuliert.


Mit einem Pfad wie /../hostname Sollten Sie in einigen frühen Pre-VFS- und Pre-NFS-Systemen wie [~ # ~] Munix [~ # ~ auf das Stammverzeichnis eines anderen Hosts zugreifen können ] (unter Verwendung der "Newcastle Connection" ), aber ich kenne kein solches System, das noch verwendet wird, und der Quellcode ist nirgends zu finden.

Die verfügbaren Informationen sind sehr widersprüchlich, aber es scheint, dass die üblichste Art, ein solches System bereitzustellen, darin bestand, alle Programme neu zu kompilieren , sodass alle Pfade verwendet werden wie open(2) konnte im Userspace umgeleitet werden (es gab zu dieser Zeit keine gemeinsam genutzten Bibliotheken).

Es gab wahrscheinlich Hunderte solcher Hacks ( Scratchbox , die jünger waren und die ich nicht benutzen musste), daher ist überhaupt nicht klar, warum sie das Bedürfnis hatten, sich anzupassen es im POSIX-Standard.

2
mosvy

Neben allen anderen hier genannten Gründen ist es Einfachheit des Designs, wofür UNIX bekannt ist. Alle Verzeichnisse enthalten ..; Sonderfälle sind immer Stolperfallen (aus Sicherheits- oder Robustheitsgründen) im Dunkeln. Anstatt Programmierer zu zwingen, sich an vielen Stellen mit einem seltenen Fall zu befassen, sind alle Verzeichnisse so konzipiert, dass sie Einträge . Und .. Haben. Sie werden einheitlich behandelt und es wird berücksichtigt, was bei / Wird nicht benötigt.

1
countermode