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

Dans l'état actuel des choses, cette question ne convient pas à notre format de questions / réponses. Nous nous attendons à ce que les réponses soient étayées par des faits, des références ou une expertise, mais cette question suscitera probablement un débat, des arguments, des sondages ou une discussion approfondie. Si vous pensez que cette question peut être améliorée et éventuellement rouverte, visitez le centre d'aide pour obtenir des conseils.

Fermé il y a 6 ans .

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
source

Voir aussi Everything by VoidTools qui fait la même chose.

— David d C e Freitas

Grands gars de travail clôturant une question avec plus de 20 votes positifs comme "pas constructif"!

— Dan Dascalescu

Réponses:

À 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
source

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

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

@ 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

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

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
source

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

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
source