Es ist technisch möglich, . zu löschen , zumindest auf EXT4-Dateisystemen. Wenn Sie ein Dateisystem-Image in test.img erstellen , mounten Sie es und erstellen Sie eine test Ordner, dann unmounten Sie es wieder, Sie können es mit debugfs bearbeiten :
debugfs -w test.img
cd test
unlink .
debugfs beschwert sich nicht und löscht brav den . Verzeichniseintrag im Dateisystem. Die test Verzeichnis ist immer noch nutzbar, mit einer Überraschung:
sudo mount test.img /mnt/temp
cd /mnt/temp/test
ls
zeigt nur
..
also . ist wirklich weg. Noch cd . , ls . , pwd verhalte dich trotzdem wie gewohnt!
Ich habe diesen Test zuvor mit rmdir . durchgeführt , aber das löscht den Inode des Verzeichnisses (riesig danke an BowlOfRed für den Hinweis), was test übrig lässt ein baumelnder Verzeichniseintrag und ist der wahre Grund für die aufgetretenen Probleme. In diesem Szenario ist die test Ordner wird dann unbrauchbar; Führen Sie nach dem Mounten des Images ls aus produziert
ls: cannot access '/mnt/test': Structure needs cleaning
und das Kernel-Log zeigt
EXT4-fs error (device loop2): ext4_lookup:1606: inode #2: comm ls: deleted inode referenced: 38913
Ausführen von e2fsck löscht in dieser Situation auf dem Bild den test Verzeichnis komplett (der Verzeichnis-Inode ist weg, also gibt es nichts wiederherzustellen).
All dies zeigt, dass . existiert als spezifische Entität im EXT4-Dateisystem. Ich habe aus dem Dateisystemcode im Kernel den Eindruck bekommen, dass er . erwartet und .. existieren, und warnt, falls nicht (siehe namei.c ), aber mit dem unlink . -basierter Test Ich habe diese Warnung nicht gesehen. e2fsck mag das fehlende . nicht Verzeichniseintrag und bietet an, das Problem zu beheben:
$ /sbin/e2fsck -f test.img
e2fsck 1.43.3 (04-Sep-2016)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Missing '.' in directory inode 30721.
Fix<y>?
Dadurch wird . neu erstellt Verzeichniseintrag.
Es gibt keine Möglichkeit, diesen Verzeichniseintrag zu entfernen. Der . Eintrag bedeutet "dieses Verzeichnis", der .. Eintrag bedeutet "Elternverzeichnis dieses Verzeichnisses". Sie sind eigentlich keine festen Links, so wird nur die Verzeichnisstruktur erstellt/dargestellt.
Wie in Anmerkungen von Lion zum Unix 6-Quellcode beschrieben Das frühe Unix hatte eine Plattendatei, in der sowohl Dateien als auch Verzeichnisse auf der Platte durch Inode-Strukturen dargestellt wurden. Es gab ein spezielles Bit, das anzeigte, dass der Dateiinhalt ein Verzeichnis war. Jeder Inode hatte einen Link zu seinem eigenen Inode, der es einer Datei ermöglichte zu wissen, in welchem Verzeichnis sie sich befand. Die Ausnahme war das '/'-Verzeichnis, das sich selbst besaß. Es gab auch einen Link zu Inhalten. Wenn ein Inode keinen Inhalt hatte, konnte er an die freie Liste zurückgegeben werden. Da ein Verzeichnis nur eine gesegnete Datei war, musste sogar ein leeres Verzeichnis einen Inhalt haben, um zu verhindern, dass es von der Garbage Collection erfasst wurde. Somit war der .. der Link des Inodes zum übergeordneten Inode und der . war da, um anzuzeigen, dass das Verzeichnis noch verwendbar war. rmdir (durch Aufrufen von unlink) könnte die . Verzeichnis, wenn es keine anderen Inhalte gäbe, und der Inode würde dann in die freie Liste verschoben, wenn es keine Verweise mehr darauf gäbe.