Hard links de repertoires ?

Dsdfkfndf,

Enchanté. Moi c'est «Miod».

Je viens de découvrir l'existence des hard links.
Si si, c'est vrai, marrez-vous.

Puisque tu nous y invites si cordialement (-:

Les archives de Google me disent que c'est en rapport avec de sombres
histoires de non-possibilité de détection de récursivité, de nombre de
fichiers père de chaque fichier, et autres blagues incongrues.

Exact. Plus simplement, de sombres histoire de graphes, et trop
d'algorithmes utilisés dans la gestion des systèmes de fichier
présupposent que ton graphe ne contient pas de cycle, parce que sinon
c'est trop la croix, la bannière et la perte de performances.

Et sinon, pas normally, y a pô moyen d'outrapasser gorêtement cette
restriction, sans trop mettre en péril la demeure ?

Non.

Euh sous SunOS 4.1.3 (qui était un BSD restons en charte) y'avait
moyen.

Il a dit «sans mettre en péril» ! Sinon, oui, le code est toujours là
chez *BSD, je crois qu'il suffit de décommenter un truc et de recompiler
ln pour l'avoir.

Mais fallait se garder son clri (clear-inode) sous la main...

Ainsi que son stock de cierges.

Mais fallait se garder son clri (clear-inode) sous la main...
Ainsi que son stock de cierges.

Et spiritus sanctus et benedicti sancti, Amen.

According to Nicolas Ecarnot <nicolas.ecarnot@alussinan.org>:

Bon ça y est, maintenant dans le man on lit que les hard links ne peuvent
pas s'appliquer aux répertoires.
Aucune raison n'est invoquée.

Les "hard links" sur répertoires posent deux problèmes, un mineur et
un majeur.

Le problème mineur est dans la sémantique de ".." qui pointe vers le
répertoire père. Avec des hard links, un répertoire pourrait avoir
plusieurs pères, et les choses deviennent floues. Le vrai ennui arrive
avec getcwd() (et /bin/pwd, qui appelle getcwd()). Cette fonction
détermine le chemin complet depuis la racine vers le répertoire courant.
Elle travaille en regardant le contenu de "..", puis de "../..", etc...
jusqu'à trouver un répertoire qui est son propre "..", c'est-à-dire la
racine. Avec des hard links sur répertoires, on peut faire des boucles,
et faire partir getcwd() dans une boucle infinie (boucle qui finit par
faire un overflow sur la pile, et un plantage pas beau). On peut
s'arranger de tout cela, mais ça demande des efforts.


Le problème majeur est une histoire de libération de place. Dans un
filesystem, chaque objet alloué (fichier, répertoire...) est libéré
automatiquement quand plus personne ne le référence. Par exemple,
supposons un fichier avec deux noms, /tmp/bla et /tmp/blu (on peut dire
que /tmp/blu est un lien dur vers /tmp/bla). Il est noté dans l'inode
du fichier qu'il y a deux références vers ce fichier. Quand j'efface
/tmp/bla, ce compteur est décrémenté et arrive à 1. Le fichier continue
d'exister. Si ensuite j'efface /tmp/blu, le compteur arrive à 0, et là
le fichier est réellement viré du disque.

Maintenant, supposons qu'avec des liens durs vers répertoires, j'ai
fait une boucle. Genre, /tmp/foo/bar est un lien dur vers /tmp/foo.
Maintenant, je supprime /tmp/foo (juste le nom) ; l'OS ne râle pas parce
que le compteur de références du répertoire en question tombe à 1 (il
reste le lien depuis /tmp/foo/bar) et donc le répertoire n'est pas viré
en fait (donc pas d'histoire de "directory not empty"). Mais maintenant,
j'ai mon répertoire qui se retrouve sans nom. Il se balade dans le
filesystem, je ne peux plus le référencer et donc je ne peux plus rien
en faire, notamment le virer, sauf en faisant un accès direct et goret
(id est, un fsck).

Les premiers Unix permettaient les liens durs sur répertoires, et ça a
été ensuite désactivé à cause de ce problème de libération de place. Un
filesystem permettant les liens durs vers répertoires devrait avoir une
sorte de "garbage collector" qui parcourt le filesystem en arrière-plan
pour libérer les répertoires. Une autre possibilité serait d'autoriser
les liens durs mais interdire les cycles, ce qui n'est pas complètement
évident à détecter.

Et sinon, pas normally, y a pô moyen d'outrapasser gorêtement cette
restriction, sans trop mettre en péril la demeure ?

Il faudrait taper dans le filesystem directement. Si on s'abstient de
faire des cycles, les seules choses à modifier sont fsck (pour qu'il ne
casse pas tout lors de son prochain passage) et le noyau (pour qu'il
agisse correctement en cas de unlink() ou rmdir() sur un répertoire avec
hard links). Si on fait un cycle, il faut s'attendre à voir /bin/pwd
planter, et à avoir des ennuis pour effacer le cycle.

pornin@nerim.net (Thomas Pornin) wrote in
news:bg2kj4$87a$1@biggoron.nerim.net:

[...]

Merci beaucoup pour ce très bon résumé de la situation.
(Ce genre de message va sans doute faire pas mal de hits dans les archives
de google à mesure des années :o)

Prenez modèles, chers gourous :o)

--
Nicolas Ecarnot

Le Thu, 24 Jul 2003 09:50:29 +0200, Marco écrivit:

Mais fallait se garder son clri (clear-inode) sous la main...
Ainsi que son stock de cierges.

Et spiritus sanctus et benedicti sancti, Amen.

^^ c'est pas sancti aussi ?

Arnaud.
--
To keep your friends treat them kindly; to kill them, treat them often.