Comment dissocier (supprimer) le lien spécial "." Créé pour un dossier?

Sous Linux, lorsque vous créez un dossier, il crée automatiquement deux liens physiques vers l'inode correspondant. Un qui est le dossier que vous avez demandé de créer, l'autre étant le . dossier spécial ce dossier.

Exemple:

 $ 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 .. 

Comme vous pouvez le voir, le folder et . Le folder interne de ce folder possède le même numéro d'inode (illustré avec l'option -i ).

Y at-il de toute façon supprimer ce spécial . hardlink?

C'est seulement pour l'expérimentation et la curiosité. Aussi, je suppose que la réponse pourrait s'appliquer à .. file spécial aussi.

J'ai essayé de regarder dans l'homme de rm mais n'a pas pu find le moyen de le faire. Quand j'essaye d'enlever tout ce que je reçois est:

rm: "." et ".." ne peuvent pas être supprimés

Je suis vraiment curieux de la façon dont ces choses fonctionnent, alors ne vous abstenez pas d'être très verbeux sur le sujet.

EDIT: Peut-être que je n'étais pas clair avec mon post, mais je veux comprendre le mécanisme sous-jacent qui est responsable . files et les raisons pour lesquelles ils ne peuvent pas être supprimés.

Je sais que le standard POSIX interdit un dossier avec less de 2 liens, mais ne comprends pas vraiment pourquoi. Je veux savoir si cela pourrait être possible de le faire quand même.

Il est techniquement possible de supprimer . , au less sur les filesystems EXT4. Si vous créez une image de système de files dans test.img , montez-la et créez un dossier de test , puis démontez-la, vous pouvez la modifier en utilisant debugfs :

 debugfs -w test.img cd test unlink . 

debugfs ne se plaint pas et consciencieusement supprime le . input de directory dans le système de files. Le directory de test est toujours utilisable, avec une surprise:

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

montre seulement

 .. 

donc . est vraiment parti. Pourtant cd . , ls . , pwd se comporte toujours comme d'habitude!

J'avais déjà fait ce test en utilisant rmdir . , mais cela supprime l'inode du directory (un grand merci à BowlOfRed pour l' avoir signalé ), ce qui laisse test une input dans le directory et est la vraie raison des problèmes rencontrés. Dans ce scénario, le dossier de test devient alors inutilisable; après le assembly de l'image, le ls produit

 ls: cannot access '/mnt/test': Structure needs cleaning 

et le journal du kernel montre

 EXT4-fs error (device loop2): ext4_lookup:1606: inode #2: comm ls: deleted inode referenced: 38913 

Exécuter e2fsck dans cette situation sur l'image supprime entièrement le directory de test (l'inode du directory a disparu, donc il n'y a rien à restaurer).

Tout cela montre cela . existe en tant qu'entité spécifique dans le système de files EXT4. J'ai eu l'printing du code de système de files dans le kernel qu'il attend . et .. d'exister, et avertit s'ils ne le font pas (voir namei.c ), mais avec le unlink . test basé sur la base Je n'ai pas vu cet avertissement. e2fsck n'aime pas les e2fsck manquants . l'input de directory et propose de le réparer:

 $ /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>? 

Cela recrée le . input de directory.

Il n'y a aucun moyen de supprimer cette input de directory. Le . input signifie "this directory", l'input .. signifie "directory parent de ce directory". Ce ne sont pas vraiment des liens durs, c'est juste comment la structure de directorys est créée / représentée.

Comme décrit dans les Notes de Lion sur le code source Unix 6, Unix disposait d'un file disque sur lequel les files et les directorys étaient représentés sur le disque par des structures inodes. Il y avait un bit spécial qui indiquait que le contenu du file était un directory. Chaque inode avait un lien avec son inode propre qui permettait à un file de savoir dans quel directory il se trouvait. L'exception était le directory '/' qui lui appartenait. Il y avait aussi un lien vers le contenu. Si un inode n'avait pas de contenu, il pourrait être renvoyé à la list libre. Comme un directory était juste un file béni, même un directory vide devait contenir du contenu pour éviter qu'il soit collecté. Ainsi, le .. était le lien de l'inode à l'inode parent et le. était là pour indiquer que le directory était toujours utilisable. rmdir (en appelant unlink) pourrait supprimer le. directory s'il n'y avait pas d'autre contenu et l'inode passerait alors à la list libre lorsqu'il n'y avait plus de references.

Comme le dit la réponse possible de post , la norme POSIX spécifie que si rmdir tente de supprimer le directory courant, il échouera.

Avec tout ce que vous construisez, vous devez avoir une fondation. Il est difficile de définir des paths relatifs sans un moyen de dire «ici». Alors le '.' est défini comme «ici».

Vous pouvez également supprimer 'point' et 'point point'. Ecrivez votre propre operating system qui ne les définit pas. Bien qu'Unix (et par extension Mac OSX), Linux, et même MS DOS et Windows utilisent tous dot et dotdot.

TL; DR – 'point' est dans la définition de l'OS.