Pourquoi les gestionnaires de fichiers n'utilisent-ils pas la table de fichiers maîtres pour des résultats de recherche instantanés? [fermé]

27

Je viens de découvrir UltraSearch et j'ai été époustouflé par sa vitesse de recherche de fichiers et de dossiers. C'est instantané . Et n'utilise aucun service d'indexation. Il utilise simplement la table de fichiers maîtres NTFS , qui stocke déjà tous les noms de fichiers sur la partition NTFS.

La question est, pourquoi cette fonctionnalité n'est-elle pas beaucoup plus populaire parmi les gestionnaires de fichiers, et dans Windows Explorer Search (Win + F) pour commencer?

windows-explorer ntfs file-search Dan Dascalescu
la source
2
Voir aussi Everything by VoidTools qui fait la même chose.
David d C e Freitas
1
Grands gars de travail clôturant une question avec plus de 20 votes positifs comme "pas constructif"!
Dan Dascalescu

Réponses:

29

À cause de la sécurité!

Voilà la vraie raison. (Et la seule vraie raison, à mon avis - ce n'est pas si difficile de faire un lecteur pour les principaux systèmes de fichiers, bien que ce ne soit pas facile; faire un écrivain est le vrai défi.)

Un programme comme celui-ci contourne toute l'infrastructure de sécurité du système (de fichiers), de sorte que seul un administrateur (ou une autre personne disposant des privilèges "Gérer le volume") peut l'exécuter.

Donc, évidemment, cela ne fonctionnerait pas dans de nombreux scénarios - et je ne pense pas que Microsoft (ou toute autre grande entreprise) envisagerait de créer un produit comme celui-ci et d'encourager ensuite les utilisateurs à s'exécuter en tant qu'administrateurs , en raison des ramifications de la sécurité.

Il serait théoriquement possible de créer un système qui s'exécute en arrière-plan et filtre les données sécurisées, mais en pratique, cela demanderait beaucoup de travail d'être correct et sans failles de sécurité pour la production.

Soit dit en passant, je n'ai pas utilisé UltraSearch, mais j'avais écrit moi-même un programme très similaire il y a quelques années que j'avais ouvert le mois dernier! Vérifiez-le si vous êtes intéressé. :)

Mehrdad
la source
1
Cela ne semble pas être une bonne raison. Le système d'exploitation peut donner une vue pour la recherche non sécurisée, tout comme un DMBS. Une API ou une vue restreinte doit donner un accès public aux fichiers publics. Et si la table de fichiers ne sait rien de la sécurité de différents répertoires, c'est probablement une mauvaise conception du côté de la conception du système d'exploitation
LifeH2O
@ LifeH2O: Le problème est que l'ajout de contrôles de sécurité va être un énorme impact sur les performances, ce qui va complètement à l'encontre du but de l'outil.
Mehrdad
1
Comment les performances peuvent-elles être supérieures à l'analyse des répertoires? Seule la sécurité des répertoires internes devra être vérifiée. Je ne sais pas ce qui peut être fait avec la table de fichiers Windows.
LifeH2O
1
@ LifeH2O: Avez-vous pensé à quel point il est compliqué de "vérifier" quelque chose? Les utilisateurs appartiennent à plusieurs groupes, les groupes et les utilisateurs peuvent chacun avoir des autorisations autoriser / refuser / ni sur un répertoire de la chaîne ou sur le fichier lui-même, et vous devez déterminer les autorisations effectives pour l'utilisateur actuel sur chaque fichier à l'aide de son ACL . Ajoutez maintenant à cela la synchronisation requise avec le sous-système du gestionnaire de sécurité du noyau, et vous obtiendrez des résultats de performances massifs simplement en "vérifiant" tous les fichiers.
Mehrdad
1
Vous devez fournir quelque chose d'autorité indiquant ce que vous dites, sinon les gens ne peuvent pas différencier la spéculation de l'information. Je suis d'accord avec les autres, c'est purement de la spéculation.
user34660
6

Les gestionnaires de fichiers doivent être en mesure de prendre en charge tous les systèmes de fichiers qui pourraient être rencontrés. En tant que tels, ils doivent appeler le VFS via son API . Il n'y a aucun moyen (sain) de renvoyer un grand tableau à partir d'un appel d'API, ce qui entraîne l'énumération des fichiers en série indépendamment de la présence d'un MFT / FAT / superbloc.

Ignacio Vazquez-Abrams
la source
1
Si vous étiez programmeur, vous sauriez comment les API gèrent de grandes quantités de données comme vous le dites. Et non, un programme de recherche n'est pas requis pour prendre en charge plusieurs systèmes de fichiers.
user34660
@ user34660: Ils ont deux choix: 1) Utiliser l'énumération. 2) Exécuter très lentement lors de la manipulation de très grands ensembles de données. Et un outil de recherche qui ne prend en charge qu'un seul système de fichiers est d'une utilité très limitée.
Ignacio Vazquez-Abrams
3

Le service d'indexation de fichiers est destiné aux utilisateurs qui souhaitent rechercher du contenu (du texte le plus probable) et des métadonnées de fichiers, pas simplement un nom de fichier. C'est pourquoi il faut beaucoup de temps pour parcourir tous les fichiers et l'index construit à partir de ces services est volumineux et relativement lent. Vous pouvez désactiver le service d'indexation dans Windows, mais l'explorateur Windows est assez stupide pour continuer à rechercher le contenu des fichiers après les noms de fichiers. Comme l'a dit Ignacio Vazquez-Abrams, les gestionnaires de fichiers ne peuvent pas tirer parti du système de fichiers de bas niveau.

néo
la source