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...

[smyley]

Une partition NTFS sous linux ? Les drivers NTFS Linux sont soit en lecture seule et c'est incomplet, soit en lecture écriture et dans ce cas ça peut endommager définitivement la partition ...

Sinon je peux bien croire que les connaissances requises pour lire directement un fichier avec FAT ne sont pas extraordinaires, mais le NTFS est "légèrement" plus complexe. Et en C#, ça va pas le faire car il faudrait pour bien faire les choses un driver niveau kernel et ce n'est pas possible dans un langage .NET. (Ni dans aucun langage s'appuyant sur une machine virtuelle).

En C++ ce serai violent (écriture d'un driver, peut être communiquer avec le driver NTFS de Windows qui ne doit pas être prévu pour ou écrire soit même un driver de système de fichier ...) et je ne vois pas comment à partir de "comparaison de fichier" arriver à une solution aussi violente et dramatique ...

[sloshy]

Bonjour,
Primo je pense que l'utilité de la chose ne nous regarde en rien, s'il voulait connaitre le meilleur moyen pour faire quelques choses c'est la question qu'il aurait poser, je crois.
Secondo, le NTFS est gérée sous linux (mis a pars les droits avance), et c'est d'ailleur un exelent point d'entree pour comprendre le système NTFS de fond en comble. (c'est opensource et écrit en C posix donc pas trop de soucis).
Tierso, pour ce qui est de créer un driver, on ne parle pas de recoder un driver pour disque dur mais bien de manipuler le driver NTFS, c'est quand même largement diffèrent (et avec le chainage de driver, c'est simplifie).

[Mac LAK]

Primo je pense que l'utilité de la chose ne nous regarde en rien, s'il voulait connaitre le meilleur moyen pour faire quelques choses c'est la question qu'il aurait poser, je crois.

Ben d'un autre côté, quand tu demandes un coup de main, c'est mieux d'expliquer clairement, précisément et le plus complètement possible ce que tu veux... Pour ma part, j'ai souvent vu des clients "exiger" telle ou telle fonction bas niveau, parce qu'ils croyaient en avoir besoin... Alors qu'une fois le besoin initial enfin déterminé réellement, dans 90% des cas ils s'étaient complètement plantés et avaient besoin de tout autre chose.

Secondo, le NTFS est gérée sous linux (mis a pars les droits avance), et c'est d'ailleur un exelent point d'entree pour comprendre le système NTFS de fond en comble. (c'est opensource et écrit en C posix donc pas trop de soucis).

Ce n'est donc pas géré correctement ni complètement...

Tierso, pour ce qui est de créer un driver, on ne parle pas de recoder un driver pour disque dur mais bien de manipuler le driver NTFS, c'est quand même largement diffèrent (et avec le chainage de driver, c'est simplifie).

(C'est "Tertio", au fait)
Ce qui n'explique toujours pas la notion de "comparaison de fichiers", surtout entre filesystems... Et toujours pas de réponse de l'OP, d'ailleurs.

[XREvo]

Bonjour,

Tout d'abord merci pour le liens et les conseils, et pardon pour le retard de ma réponse (j'ai eu quelques soucis personnel qui m'ont forcé à être ... absent durant quelques temps).

Ensuite, je suis d'accord avec vous lorsque vous dites que l'accès bas niveau n'est pas utile pour une comparaison de fichiers (ce qui semble logique en soit). C'est d'ailleurs mon avis, mais je ne suis malheureusement pas le seul à travailler sur le projet, et mon pote m'a affirmé que ça nous serait utile (je suis forcé d'avouer que le jour où il m'a expliqué l'utilité, je n'étais pas très sobre).

Quoiqu'il en soit, merci pour le lien Mac LAK et merci Melem pour le conseil sur les control codes. J'ai désormais une piste de réflexion sur laquelle je vais surement passer le reste de ma nuit afin de trouver un moyen d'avoir un accès bas niveau aux fichiers (tout en attendant que mon pote est fini de déménager pour que je le prenne à part et qu'il m'(ré)explique sur quoi il se base pour estimer qu'on en a besoin).

Encore merci à tous, je reviendrais surement dans les jours qui suivent pour plus d'informations.

@ Bientôt

[Mac LAK]

mon pote m'a affirmé que ça nous serait utile

J'avoue que je serais curieux d'avoir l'explication...