2009-03-30 5 views
3

Je pense à implémenter un programme de recherche de fichiers en utilisant l'indexation sous linux ... Je sais qu'il existe plusieurs autres programmes de recherche de fichiers comme beagled. mais je fais cela à des fins d'étude ... Je suis frappé de la façon de faire l'indexation .. J'ai l'idée suivante que j'ai pris de l'application maemo-mapper .. par exemple si vous avez un fichier nommé "suresh" son index dans le système de fichiers sous forme de fichiers ...Algorithmes de recherche de fichiers utilisant l'indexation dans linux

/home/$USERNAME/.file_search_index/s/u/r/e/s/h/list.txt .. Cette liste.txt contient l'emplacement de tous les fichiers avec le nom = "suresh" ... SVP suggérer une meilleure idée/algorithme pour l'implémenter ... Et s'il y a du matériel sur divers techniques de recherche de fichiers, veuillez le poster ....

+0

Je ne sais pas pourquoi cela a été downvoted, il semble être une question valide. –

+0

Je ne sais pas pourquoi quelqu'un a voté pour fermer cela non plus. S'il vous plaît, ne craignez pas les pingouins ... nous avons aussi des questions :) –

Répondre

4

Vous n'avez pas vu la commande locate qui vient avec findutils? Comme beagled, c'est un logiciel gratuit, donc vous pouvez étudier le code.

Le paquet findutils est toujours à la recherche de contributeurs.

Informations sur le format de base de données est à http://www.gnu.org/software/findutils/manual/html_node/find_html/Database-Formats.html

+0

Il y a aussi http://slocate.trakker.ca/ et http://carolina.mff.cuni.cz/~trmac/blog/mlocate/ (bien que le localisateur GNU Findutils soit le plus largement installé) – ephemient

+0

Salut, vous connaissez les intrenals de localiser ou avez-vous un doc/lien dessus? Pourquoi je me pose cette question Cela fait gagner du temps en évitant l'affichage du code de locate et updatedb – suresh

+0

Oui, il y a de la documentation. Ajoutée. – ashawley

1

Beagle utilise une approche très intéressante avec inotify. Il démarre, établit une surveillance sur le répertoire parent et démarre un autre thread qui effectue une analyse récursive. Au fur et à mesure que l'on accède à plus de répertoires, le parent les voit et ajoute plus de montres, tout en regardant ce qu'il sait déjà. Donc, quand il a commencé, vous regardez un arbre entier assez bon marché (une montre par répertoire) et vous avez tout indexé. Cela permet également de s'assurer qu'aucun fichier n'est «manqué» pendant l'analyse. Donc, c'est la plus grande partie de votre bataille ... typiquement, les programmes de recherche FS atteignent leur point faible lors de l'indexation, par exemple 'updatedb'.

En ce qui concerne le stockage de l'index, je ne serais pas en faveur de le diviser en répertoires. Vous appelez par essence stat() sur chaque caractère d'un tableau de noms de fichiers. some-very-long-shared-object-name.so.0 par exemple serait un appel à stat() pour chaque caractère du nom. Vous pouvez essayer d'utiliser une base de données SQLite3 bien conçue. Je travaille sur quelque chose de très similaire, un programme pour fournir des moyens d'audit un peu moins cher pour la certification PCI (processeur de carte de crédit), sans utiliser les crochets d'audit du noyau.

+0

Pourquoi ne pas utiliser la division des répertoires ... Je peux trouver tous les fichiers dans l'index par lookin fichier unique .... donc c'est la récupération est o (n) ... Temps pris par le système de fichiers OS pour récupérer un fichier ... Je dois inotify pour voir toutes les modifications sont faites aux dossiers dans le système de fichiers .... – suresh

+0

C'est les appels éventuels (et inévitables) à stat() qui me donnent envie d'éviter cette approche. Chaque recherche serait aussi chère que le nom du fichier est long. –

+1

Je ne vais pas faire stat sur chaque dossier .. Je vais former une chaîne "/home/$USERNAME/.file_search_index/s/u/r/e/s/h/list.txt" et ne stat sur que ce list.txt .... et ouvrir ce fichier pour la liste des résultats de la recherche ... – suresh

Questions connexes