comment trouver une boucle dans le système de fichiers?

J’ai trouvé ce commentaire intéressant sur la recherche de boucles dans un DAG :

Steinar H. Gunderson a écrit:

Le jeudi 26 février 2004 00:28:32 +0100, Orlondow a écrit:

… également reproduit dans le Cormen-Leiserson-Rivest, IIC. Le plus facile à trouver

Oui, j’ai en fait Cormen et al, mais cela ne m’a jamais frappé de rechercher des «composants fortement connectés» lorsque je voulais détecter le cycle. Merci, je vais le regarder. 🙂

Pour trouver un cycle dans un graphe orienté (vous ne vous souciez pas de quel cycle) tant qu’il en existe un, vous n’avez pas besoin de dépasser SCC. Il est suffisant de commencer par la recherche DFS (dans le même chapitre de CLRS).

Donc, grosso modo, lorsque vous parcourez l’arborescence de répertoires, créez un DAG qui représente la structure de l’arborescence avec les données du nœud faisant référence à l’inode du fichier. Ensuite, il vous suffit de vérifier que vous ne visitez pas plusieurs nœuds.

La manière générale d’empêcher le réexamen des noeuds dans un graphique consiste à marquer les noeuds au fur et à mesure que vous les transmettez, puis à ignorer les noeuds marqués. Ce n’est pas très pratique si vous ne souhaitez pas modifier le graphique que vous parsingz, vous avez donc besoin d’un moyen de marquer les noeuds en externe. Le moyen le plus simple de le faire sous Linux serait de stocker le périphérique / inode pour chaque répertoire que vous visitez. Ensuite, quand vous regardez un répertoire, vérifiez d’abord que vous n’avez pas encore vu de répertoire avec le même périphérique / inode. Cela ne gère pas seulement les cycles, mais aussi les arbres qui se rejoignent.

Pour obtenir le numéro de périphérique / inode, examinez les fonctions stat / fstat et les membres st_dev et st_ino de la structure de statistiques.

Pour stocker les données, vous voulez probablement regarder une table de hachage ou un arbre binary.

Btw. Vous n’avez pas besoin de rechercher une boucle dans le système de fichiers.

Vous indexez le disque entier. Vous n’avez donc pas besoin de suivre les liens symboliques car chaque fichier doit être accessible de manière normale (sans liens symboliques). Il suffit de vérifier les points de assembly si un disque est monté plusieurs fois, ignorez simplement les points de assembly restants.

Peut-être que je suis un peu sombre ici, mais ce ne sont pas les deux façons de créer un cycle:

• en créant un lien symbolique
• en montant quelque chose deux fois

Pour y faire face, vous pouvez obtenir une liste des assemblys avant de commencer à indexer et, si ce n’est pas le cas, le premier des mêmes éléments, et vous pouvez ignorer les liens lorsque vous les rencontrez dans le processus d’indexation.

Manière simple Il vous suffit de parcourir l’arborescence en profondeur, en gardant une stack de nœuds au-dessus de vous. A chaque nœud que vous visitez, si ce nœud est déjà dans la stack, vous avez un cycle.

// here's a stack of nodes node stack[1000]; walk(node, level){ if (node in stack[0..level-1]) then there is a cycle else stack[level] = node for each subnode x of node walk(x, level+1) } 

Comme d’autres l’ont déjà dit, une boucle dans un système de fichiers n’existe pas si vous réalisez que le chemin fait partie d’un nom de fichier, sauf s’il s’agit d’un lien symbolique cyclique.

Par exemple, si vous amorcez une dissortingbution (disons Debian) sur un périphérique en boucle, ou même sur un répertoire, et que vous faites ceci sur une machine Debian, vous avez maintenant dupliqué beaucoup de choses.

Par exemple, disons que vous utilisez Debian Lenny et que vous en copiez une copie minimale sur / lenny.

/ lenny / usr / * sera identique à / usr / *. Il n’y a pas de moyen «bon marché» d’éviter cela.

Puisque vous appelez déjà un stat () sur chaque nœud (je suppose que vous utilisez ftw () / ftw64 (), vous pouvez aussi:

• Faites en sorte que le rappel de ftw () insère le nom du nœud dans un tableau, avec des membres de structure capables de stocker un hachage du fichier qui ne risque pas de se heurter. md5 ne va pas le couper pour ça.
• Mettre à jour une table de hachage basée sur ce résumé et le nom du fichier (pas le chemin).

Cela ne risque pas d’accélérer votre parsing, mais cela réduira considérablement le temps de recherche.

Si vous utilisez les threads correctement et définissez l’affinité, le hachage et l’indexation peuvent se produire sur un core alors que l’autre est lié (lorsque plusieurs cores sont disponibles).

Cependant, la vérification des assemblys en double ne sera pas un remède, et je suis sûr que votre programme voudra renvoyer les emplacements de tous les fichiers nommés “foo”, même s’il y a quatre copies identiques à mentionner.

Ceci est plus généralement appelé un “cycle”. Donc, vous voulez implémenter “détection de cycle”. Il y a plusieurs façons de le faire. Je ne sais pas si c’est pour le travail à domicile ou non, mais une méthode simple, pas nécessairement la plus optimale, passe par la chasse au pointeur.