2010-06-22 6 views

Répondre

4

En raison de liens physiques, plusieurs chemins peuvent être mappés vers les numéros VolumeSerialNumber et FileIndex. Pour trouver tous ces chemins:

  1. volumes de Iterate pour trouver celui dont correspond le répertoire racine dwVolumeSerialNumber
  2. récursive énumérer tous les répertoires sur le volume, en sautant les liens symboliques et des points d'analyse, de trouver tous les fichiers avec correspondance nFileIndexHigh et nFileIndexLow.

Cela peut prendre beaucoup de temps. Si vous avez vraiment besoin de le faire aussi vite que possible et que votre système de fichiers est NTFS, vous pouvez lire l'intégralité de la MFT dans un tampon et l'analyser vous-même. Cela va obtenir tous les répertoires qui correspondent à l'intérieur d'une entrée MFT d'un seul coup. Le reste des répertoires peut être lu via le système d'exploitation ou également à travers des lectures brutes, en fonction de la quantité de travail que vous voulez faire. Mais de toute façon vous le regardez, c'est un lot de travail et ne s'applique même pas à FAT, FAT32 ou tout autre système de fichiers.

Une meilleure solution est probablement de rester sur le chemin d'origine si cela est possible.

1

Remarque: La question originale comportait une erreur. Maintenant que la question a été corrigée, cette réponse ne s'applique plus.


En général, vous ne pouvez pas. Les informations que vous avez récupérées vous indiquent le disque sur lequel le fichier se trouve et la taille de celui-ci. Il ne fournit pas suffisamment d'informations pour identifier le fichier réel. Plus précisément:

  • dwVolumeSerialNumber identifie le volume et
  • nFileSizeHigh et nFileSizeLow vous donner la taille du fichier

Si le fichier se trouve être le seul fichier sur ce volume est que la taille exacte , vous pouvez rechercher dans le volume un fichier de cette taille. Mais en général, c'est à la fois cher et peu fiable, donc je ne le recommande pas.

+0

Pourquoi le downvote? La réponse est correcte, et je crois que c'est la meilleure réponse qui puisse être donnée. –

+0

Erreur dans la description .. Je voulais dire nFileIndexHigh et nFileIndexLow, pas la taille du fichier. Fixé. – skevar7

+0

Ok, c'est logique. Mais ma réponse n'a-t-elle pas été utile dans le sens où elle vous a fait réaliser l'erreur dans votre description? –

4

Ce MSDN article montre comment obtenir le chemin à partir d'un descripteur de fichier.

Vous utilisez OpenFileById pour ouvrir un fichier donné son ID de fichier, mais vous avez également besoin d'un fichier ouvert ailleurs sur le même volume, je suppose d'obtenir le numéro de série du volume.

This blog posting soulève un problème intéressant que vous devez passer en 24 pour la taille de la structure (élaboré en regardant le code d'assemblage). Je laisse comme un exercice intéressant (je ne trouvais pas de réponse facile) comment vous allez d'un dwVolumeSerialNumber à avoir un autre handle valide ouvert pour ce volume ou un fichier sur ce volume, mais peut-être que vous avez déjà assez informations pour votre cas. Une possibilité est d'itérer tous les volumes montés en appelant GetVolumeInformation pour trouver celui avec le numéro de série correspondant.Remarque: Si vous n'avez pas le fichier ouvert, vous ne pourrez peut-être pas utiliser le combo nFileIndexHigh/Low (ID de fichier aka) comme décrit dans le BY_HANDLE_FILE_INFORMATION Structure notes, qui avertit qu'il peut changer pour les systèmes FAT, mais Dans le système de fichiers NTFS, un fichier conserve le même ID de fichier jusqu'à sa suppression.

+0

Notez que cette solution a quelques limitations. 'GetFinalPathNameByHandle()' (Vista et versions ultérieures) résout les liens symboliques et l'implémentation 'GetFileNameFromHandle()' (pour Windows XP) ne fonctionne pas avec les fichiers vides. – simonzack

Questions connexes