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

29

Sous Linux, lorsque vous créez un dossier, il crée automatiquement deux liens durs vers l'inode correspondant. L'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, les deux folderet à .l'intérieur folderont le même numéro d'inode (montré avec -ioption).

Est-il possible de supprimer ce .lien spécial ?

C'est uniquement pour l'expérimentation et la curiosité. Je suppose que la réponse pourrait également s'appliquer au ..fichier spécial.

J'ai essayé de regarder l' rmhomme mais je n'ai trouvé aucun moyen de le faire. Lorsque j'essaie de supprimer .tout ce que j'obtiens, c'est:

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

Je suis vraiment curieux de savoir comment ces choses fonctionnent, alors ne vous abstenez pas d'être très bavard sur le sujet.

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

Je sais que la norme POSIX interdit un dossier avec moins de 2 liens physiques, mais je ne comprends pas vraiment pourquoi. Je veux savoir s'il serait possible de le faire de toute façon.

Fantattitude
la source
11
Duplication possible de Pourquoi ne puis-je pas supprimer le '.' annuaire?
Stephen Kitt
@StephenKitt Veuillez voir ma modification.
Fantattitude
1
J'ai rétracté mon vote, voyons comment se déroule le vote ...
Stephen Kitt
2
Les deux sont nécessaires pour les chemins relatifs. pourquoi voudriez-vous les supprimer (autre que la simple curiosité)?
HalosGhost du
@HalosGhost Je suis juste très curieux, haha, explorant les limites du système et comment et pourquoi il a été conçu de cette façon.
Fantattitude

Réponses:

46

Il est techniquement possible de supprimer ., au moins sur les systèmes de fichiers EXT4. Si vous créez une image de système de fichiers dans test.img, montez-la et créez un testdossier, puis démontez-la à nouveau, vous pouvez la modifier en utilisant debugfs:

debugfs -w test.img
cd test
unlink .

debugfsne se plaint pas et supprime consciencieusement l' .entrée de répertoire dans le système de fichiers. Le testrépertoire est toujours utilisable, avec une surprise:

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

montre seulement

..

c'est .vraiment parti. Pourtant cd ., ls ., pwdse comportent toujours comme d' habitude!

J'avais déjà fait ce test en utilisant rmdir ., mais cela supprime l'inode du répertoire ( merci énormément à BowlOfRed pour l' avoir signalé ), ce qui laisse testune entrée de répertoire pendant et est la vraie raison des problèmes rencontrés. Dans ce scénario, le testdossier devient alors inutilisable; après avoir monté l'image, l'exécution lsproduit

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

et le journal du noyau montre

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

L'exécution e2fsckdans cette situation sur l'image supprime testentièrement le répertoire (l'inode du répertoire a disparu, il n'y a donc rien à restaurer).

Tout cela montre qu'il .existe en tant qu'entité spécifique dans le système de fichiers EXT4. J'ai eu l'impression du code du système de fichiers dans le noyau qu'il attend .et ..exister, et avertit s'ils ne le font pas (voir namei.c), mais avec le unlink .test basé sur je n'ai pas vu cet avertissement. e2fsckn'aime pas l' .entrée de répertoire manquante et propose de la corriger:

$ /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 l' .entrée de répertoire.

Stephen Kitt
la source
Très intéressant! Merci! Le .dossier existe donc vraiment à l'intérieur du FS et les outils s'attendent à ce qu'il fonctionne correctement.
Fantattitude
Vraiment gentil de votre part, je ne connais pas suffisamment Linux et ses FS pour trouver ce genre d'informations moi-même donc je suis très reconnaissant que vous preniez le temps de me répondre :)
Fantattitude
3
Pouvez-vous essayer de changer "rmdir" (qui supprime réellement l'inode) en "unlink" (qui supprime uniquement l'entrée de répertoire). Il semble laisser un répertoire fonctionnant principalement (aucune erreur sur mountou ls). Je n'ai pas vu si d'autres problèmes surgissaient.
BowlOfRed du
@BowlOfRed je vous remercie beaucoup, c'est un très bon point - donc mon rmdir .était en fait en train de détruire testet de laisser cela comme une entrée de répertoire pendante, ce qui pourrait entraîner des problèmes. Je vais vérifier unlinket mettre à jour ma réponse!
Stephen Kitt
1
@GiacomoCatenazzi pas directement, les autorisations et la propriété sont stockées dans l'inode, pas dans l'entrée de répertoire.
Stephen Kitt
5

Il n'y a aucun moyen de supprimer cette entrée de répertoire. L' .entrée signifie "ce répertoire", l' ..entrée signifie "le répertoire parent de ce répertoire". Ce ne sont pas vraiment des liens durs, c'est juste la façon dont la structure du répertoire est créée / représentée.

John
la source
Je le sais, je suis juste curieux de savoir si c'est possible car ils semblent être des liens physiques. S'ils ne le sont pas, pourquoi ajouteraient-ils au nombre de liaisons matérielles de l'inode?
Fantattitude
3
> Ce ne sont pas vraiment des liens durs, c'est comme ça que la structure du répertoire est créée / représentée. Aussi, dupliquez. unix.stackexchange.com/questions/289385/…
Xalorous
@Xalorous Et donc qu'est-ce qui représente exactement ces fichiers spéciaux, s'ils ne sont pas des liens physiques, quels sont-ils? Ils existent donc ils doivent être quelque part, sauf s'ils sont montrés lsautomatiquement par ou d'autres outils automatiquement, ce qui ne me semble pas réaliste.
Fantattitude
@Fantattitude ils sont la façon dont le dossier se représente pour implémenter l'exigence POSIX que rmdir ne puisse pas supprimer le PWD.
Xalorous
1
Dans les systèmes de fichiers Unix traditionnels, ce sont de vrais liens durs. Ils sont synthétisés à la volée par le pilote pour d'autres systèmes de fichiers.
Barmar
2

Comme décrit dans Lion's Notes sur le code source d'Unix 6Unix début avait un fichier disque où les fichiers et les répertoires étaient représentés sur le disque par des structures inodes. Il y avait un bit spécial qui indiquait que le contenu du fichier était un répertoire. Chaque inode avait un lien vers son inode propriétaire qui permettait à un fichier de savoir dans quel répertoire il se trouvait. L'exception était le répertoire «/» qui lui appartenait. Il y avait également un lien vers le contenu. Si un inode n'avait pas de contenu, il pouvait être renvoyé à la liste gratuite. Puisqu'un répertoire n'était qu'un fichier béni, même un répertoire vide devait avoir du contenu pour l'empêcher d'être récupéré. Ainsi, le .. était le lien de l'inode avec l'inode parent et le. était là pour indiquer que le répertoire était toujours utilisable. rmdir (en appelant unlink) pourrait supprimer le fichier.

verisimilidude
la source
0

Comme le dit le «double possible de» la réponse de la publication , la norme POSIX spécifie que si rmdir tente de supprimer le répertoire en cours, il échouera.

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

Vous pouvez également supprimer «point» et «point point». Écrivez votre propre système d'exploitation qui ne les définit pas. Bien qu'Unix (et par extension Mac OSX), Linux et même MS DOS et Windows utilisent tous des points et des points.

TL; DR - «point» est dans la définition de l'OS.

Xalorous
la source
Cette réponse est bonne surtout pour le TL; DR.
Joshua