Wie kann ich den speziellen Hardlink "." Entfernen, der für einen Ordner erstellt wurde?

Wenn Sie unter Linux einen Ordner erstellen, werden automatisch zwei feste Links zum entsprechenden Inode erstellt. Einer ist der Ordner, den Sie erstellen möchten, der andere ist der .spezielle Ordner dieses Ordners.

Beispiel:

$ mkdir folder
$ ls -li
total 0
124596048 drwxr-xr-x    2 fantattitude  staff    68 18 oct 16:52 folder
$ ls -lai folder
total 0
124596048 drwxr-xr-x  2 fantattitude  staff   68 18 oct 16:52 .
124593716 drwxr-xr-x  3 fantattitude  staff  102 18 oct 16:52 ..

Wie Sie sehen können, haben beide folderund .die Innenseite folderdie gleiche Inode-Nummer (wird mit der -iOption angezeigt ).

Gibt es überhaupt eine Möglichkeit, diesen speziellen .Hardlink zu löschen ?

Es ist nur zum Experimentieren und zur Neugier. Ich denke auch, dass die Antwort auch auf ..spezielle Dateien zutreffen könnte .

Ich habe versucht, den rmMenschen zu untersuchen, konnte aber keinen Weg finden, es zu tun. Wenn ich versuche, .alles zu entfernen, was ich bekomme, ist:

rm: "." und ".." dürfen nicht entfernt werden

Ich bin wirklich neugierig auf die ganze Funktionsweise dieser Dinge, also hören Sie nicht auf, sehr ausführlich zu diesem Thema zu sein.

EDIT: Vielleicht war mir mit meinem Beitrag nicht klar, aber ich möchte den zugrunde liegenden Mechanismus verstehen, der für .Dateien verantwortlich ist , und die Gründe, warum sie nicht gelöscht werden können.

Ich weiß, dass der POSIX-Standard einen Ordner mit weniger als 2 Hardlinks nicht zulässt, verstehe aber nicht wirklich, warum. Ich möchte wissen, ob es trotzdem möglich sein könnte.

Es ist technisch möglich ., zumindest auf EXT4-Dateisystemen zu löschen . Wenn Sie ein Dateisystem-Image erstellen test.img, hängen Sie es ein und erstellen Sie eintest Ordner , und es dann wieder abmounten, können Sie es bearbeiten, indem Sie Folgendes verwenden debugfs:

debugfs -w test.img
cd test
unlink .

debugfs beschwert sich nicht und löscht pflichtbewusst die . Verzeichniseintrag im Dateisystem. Das testVerzeichnis ist immer noch verwendbar, mit einer Überraschung:

sudo mount test.img /mnt/temp
cd /mnt/temp/test
ls

zeigt nur

..

also ist .wirklich weg. Nochcd . , ls ., pwdverhalten sich immer noch wie gewohnt!

Ich habe diesen Test zuvor mit ausgeführt rmdir ., aber das löscht den Inode des Verzeichnisses (ein großes Dankeschön an BowlOfRed für diesen Hinweis ), wodurch testein baumelnder Verzeichniseintrag zurückbleibt und der eigentliche Grund für die aufgetretenen Probleme ist. In diesem Szenario wird der testOrdner dann unbrauchbar. nachdem die Bildmontage, Lauf lsproduziert

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

Wenn Sie e2fsckin dieser Situation auf dem Image ausführen, wird das testVerzeichnis vollständig gelöscht (der Verzeichnis-Inode ist nicht mehr vorhanden, sodass nichts wiederhergestellt werden muss).

All dies zeigt, dass .es im EXT4-Dateisystem eine bestimmte Entität gibt. Ich habe durch den Dateisystemcode im Kernel den Eindruck gewonnen, dass er erwartet .und ..existieren wird, und habe gewarnt, wenn sie dies nicht tun (siehe namei.c), aber beim unlink .-basierten Test habe ich diese Warnung nicht gesehen. e2fsckmag den fehlenden .Verzeichniseintrag nicht und bietet an, ihn zu reparieren:

$ /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 der .Verzeichniseintrag neu erstellt .

Es gibt keine Möglichkeit, diesen Verzeichniseintrag zu entfernen. Der .Eintrag bedeutet "dieses Verzeichnis", der ..Eintrag "das übergeordnete Verzeichnis dieses Verzeichnisses". Es handelt sich nicht wirklich um harte Links, nur so wird die Verzeichnisstruktur erstellt / dargestellt.

Wie beschrieben in Lion's Notes zum Unix 6-Quellcode beschriebenFrüh hatte Unix eine Festplattendatei, in der sowohl Dateien als auch Verzeichnisse durch Inode-Strukturen auf der Festplatte dargestellt wurden. Es gab ein spezielles Bit, das darauf hinwies, dass der Dateiinhalt ein Verzeichnis war. Jeder Inode hatte einen Link zu seinem eigenen Inode, über den eine Datei erkennen konnte, in welchem ​​Verzeichnis er sich befand. Die Ausnahme war das Verzeichnis '/', dessen Eigentümer er war. Es gab auch einen Link zum Inhalt. Wenn ein Inode keinen Inhalt hatte, konnte er zur freien Liste zurückgebracht werden. Da ein Verzeichnis nur eine gesegnete Datei war, musste selbst ein leeres Verzeichnis Inhalt haben, um zu verhindern, dass Müll gesammelt wird. Somit war das .. die Verknüpfung des Inodes mit dem übergeordneten Inode und dem. war dort, um anzuzeigen, dass das Verzeichnis noch benutzbar war. rmdir (durch Aufrufen von unlink) könnte das entfernen.

Als "mögliches Duplikat von" Beitrag Antwort des Postings angegeben, schlägt der POSIX-Standard fehl, wenn rmdir versucht, das aktuelle Verzeichnis zu entfernen.

Mit allem, was Sie bauen, müssen Sie ein Fundament haben. Es ist schwer, relative Pfade zu definieren, ohne dass man "hier" sagen kann. Also das '.' wird als "hier" definiert.

Auch du kannst "dot" und "dot dot" entfernen. Schreiben Sie Ihr eigenes Betriebssystem, das sie nicht definiert. Obwohl Unix (und in der Erweiterung Mac OSX), Linux und sogar MS DOS und Windows alle Punkt und Punkt verwenden.

TL; DR - "Punkt" ist in der Definition des Betriebssystems.