Discussion :

[XREvo]

Bonjour,

Je travaille actuellement avec un ami sur un projet de comparaison de fichier, dans lequel nous avons besoin d'avoir un accès bas niveau aux fichiers. J'entend par accès bas niveau d'avoir accès, par exemple, aux différents clusters (blocs) d'un fichier, quelque soit le système de fichier, afin de pouvoir en récupérer quelques informations utiles à notre comparaison.

Malheureusement, ni mon ami ni moi n'avons de connaissances dans le domaine de l'accès bas niveau aux fichiers sous Windows. Nous savons comment fonctionne FAT et NTFS (les 2 systèmes de fichiers visés par notre projet), mais nous ne savons pas comment les attaquer depuis une appli Windows (codé en VC++ ou C# par exemple). Nous avons effectué quelques recherches sur internet, mais nous n'avons rien trouvé de concluent.

Existe-t-il d'après vous des API qui permette de lire un fichier clusters après clusters par exemple ? (ça nous aiderais bien ) [Pour Windows si possible étant donné qu'il s'agit de l'OS ciblé pour notre projet]

Si de telles API n'existe pas, possédez-vous des connaissances ou des idées dans le domaine, qui pourrait nous servir de fil conducteur et ainsi nous servir à créer une API de ce genre ?

Je reste disposition si vous avez des questions ou des remarques éventuelles vis-à-vis de ce que je viens d'écrire.

Merci de votre aide. Bonne journée.

Cordialement,
--
XR

[Mac LAK]

Heu... A part comparer les systèmes de fichier eux-mêmes, en quoi un accès bas niveau au filesystem serait-il d'une quelconque utilité ?? Et même dans le cadre d'une comparaison des filesystem, ça resterait probablement inutile...

Il faudrait pour ça "décoder" à la main les données du filesystem, chose que l'OS fera bien mieux (et plus vite !) que toi à la main... Ne serait-ce qu'à cause des changements de contexte entre l'espace utilisateur et l'espace kernel !!

Si tu as besoin d'informations bas niveau sur un disque, tu peux aller voir sur cette page. Mais tenter de lire "à la main" une partition NTFS est un casse-gueule de première par contre, il vaut mieux que tu sois prévenu.


Peux-tu mieux expliciter ton besoin initial, et pour quelle raison tu penses avoir besoin d'un tel accès ?

[Melem]

Heu... A part comparer les systèmes de fichier eux-mêmes, en quoi un accès bas niveau au filesystem serait-il d'une quelconque utilité ?? Et même dans le cadre d'une comparaison des filesystem, ça resterait probablement inutile...

Ca peut toujours servir à implémenter un défragmenteur, lire une partie d'un fichier endommagé, supprimer un fichier qui ne peut pas être supprimé depuis le shell (bug de Windows, je ne sais pas si ça t'es déjà arrivé mais ça m'arrive assez souvent, et pas qu'à moi ...), accéder pour une quelconque raison au secteur de boot, etc.

Pour accéder à un disque, il suffit de créer un handle vers le disque à lire ou à écrire. Voir pour ça la doc de CreateFile. Utiliser ensuite SetFilePointer pour naviguer dans le disque et ReadFile et WriteFile pour les E/S.

Pour les informations générales concernant le disque (comme quelle est la taille d'un secteur, etc.), utiliser les control codes. Cf le lien de Mac LAK.

[Mac LAK]

Ca peut toujours servir à implémenter un défragmenteur, lire une partie d'un fichier endommagé, supprimer un fichier qui ne peut pas être supprimé depuis le shell (bug de Windows, je ne sais pas si ça t'es déjà arrivé mais ça m'arrive assez souvent, et pas qu'à moi ...), accéder pour une quelconque raison au secteur de boot, etc.

Certes, mais quel rapport avec la comparaison de fichiers ?
Défragmenteur ? OK, sauf qu'il en existe déjà des tonnes, les Windows récents (2000 et plus) défragmentent en tâche de fond de toutes façons...
Secteur de boot ? C'est mille fois plus simple de le faire via les accès BIOS, sans charger l'OS, et c'est souvent par là qu'il faut en passer de toutes façons, vu que seule la BIOS est utilisable au démarrage (si l'on veut son propre LILO par exemple).

Non, vraiment, surtout pour une comparaison de fichiers entre deux filesystems, je n'arrive pas à comprendre l'intérêt d'un accès bas niveau...
Comparer les données internes ? Les fonctions de haut niveau sont plus rapides et pratiques (fonctions CLib / STL par exemple).
Comparer les performances de chargement ? On fait alors des accès simplifiés (API Win32 "direct"), mais toujours pas besoin d'accès aussi bas niveau.

(P.S. : pour le bug de suppression, ce n'en est souvent pas un... C'est le plus souvent un handle mal fermé, Process Explorer et un autre outil en ligne de commande des SysInternals devrait pouvoir t'aider)

[Melem]

Certes, mais quel rapport avec la comparaison de fichiers ?

Ah, j'ai pas tout lu en effet ...

Défragmenteur ? OK, sauf qu'il en existe déjà des tonnes, les Windows récents (2000 et plus) défragmentent en tâche de fond de toutes façons ...

Et qui est-ce qui dit que l'algo utilisé est optimal ?

Secteur de boot ? C'est mille fois plus simple de le faire via les accès BIOS, sans charger l'OS, et c'est souvent par là qu'il faut en passer de toutes façons, vu que seule la BIOS est utilisable au démarrage (si l'on veut son propre LILO par exemple).

Ah non, vraiment tout sauf le BIOS. Ici je ne parle pas de coder un programme de boot (auquel cas il faut faire quelques échanges avec le BIOS ...) mais d'accéder au MBR sous Windows, pour y placer un programme amorçable par exemple ou, comme je l'ai dit, pour une quelconque autre raison.

P.S. : pour le bug de suppression, ce n'en est souvent pas un... C'est le plus souvent un handle mal fermé, Process Explorer et un autre outil en ligne de commande des SysInternals devrait pouvoir t'aider

Non non, je parle vraiment d'un bug que tu n'as peut-être pas encore rencontré. Tu peux redémarrer ton PC 1000, en mode sans échec, en mode je ne sais plus, mais impossible de supprimer le fichier. J'ai constaté qu'il s'agit souvent de fichiers qui n'ont pas pu être copiés (mais qui ont déjà eu des entrées (éventuellement incomplètes ...) dans table d'allocation !) ou des fichiers créés depuis Linux (je ne me rappelle plus quelle distribution j'utilisais à l'époque).

Ceci étant, je ne trouve pas en effet la nécessité d'avoir un accès bas niveau au disque pour faire une comparaison de fichiers.

[nicolas.sitbon]

ou des fichiers créés depuis Linux (je ne me rappelle plus quelle distribution j'utilisais à l'époque).

ça je confirme, ça m'est encore arrivé récemment avec un encodage à la con que Windows n'arrivait pas à gérer. Même Dos refusait de le supprimer.

[Mac LAK]

Non non, je parle vraiment d'un bug que tu n'as peut-être pas encore rencontré. Tu peux redémarrer ton PC 1000, en mode sans échec, en mode je ne sais plus, mais impossible de supprimer le fichier. J'ai constaté qu'il s'agit souvent de fichiers qui n'ont pas pu être copiés (mais qui ont déjà eu des entrées (éventuellement incomplètes ...) dans table d'allocation !) ou des fichiers créés depuis Linux (je ne me rappelle plus quelle distribution j'utilisais à l'époque).

Jamais eu : faut dire aussi que je n'ai pas de Linux (en dehors d'une VM utilisée tous les 36 du mois), et même si j'en avais un, je ne jouerais pas à monter mes partitions NTFS avec...