Discussion :

[alpha35]

Bonjour,

Je cherche à développer un outil qui permet de lire un fichier qui est en cours d'écriture par un autre process, sous Windows XP. Je me souviens de mes cours d'OS où on nous expliquait que Windows n'est pas super flexible en terme d'accès multiples aux fichiers disques, contrairement aux OS Unix.
Je n'ai malheureusement pas la possibilité de modifier le programme d'écriture.

Pour résumer, un prog 1.exe écrit continuellement des données toutes les secondes dans un fichier log.txt. Je cherche à écrire un programme 2.exe capable de lire ce fichier log.txt toutes les 5 secondes et faire une traitement spécifique lorsqu'une condition spécifique est rencontrée dans les données de log.txt.

L'OS ne permet pas l'accès au fichier log.txt tant que 1.exe tourne.

La seule solution qu'on m'a soufflé est d'utiliser le Windows Volume Shadow Service pour être capable de copier log.txt et de lire la copie avec 2.exe, ce qui ne me satisfait pas car l'étape de copie prend de plus en plus de temps au fur et à mesure que le fichier log.txt grossi.

Je pensais à utiliser une architecture réseau pour permettre la lecture et l'écriture du fichier par un système unix. Est-ce possible faire ce type d'architecture sur un portable sans connexion réseau physique ?

Une autre idée est de rediriger le fichier vers une entrée d'un autre process, capable de dupliquer les données entre un enregistrement et une routine de traitement. Existe-il un soft ou connaissez vous un exemple de source qui permet de le faire ?

Merci pour votre aide.

[Jenna]

Je me souviens de mes cours d'OS où on nous expliquait que Windows n'est pas super flexible en terme d'accès multiples aux fichiers disques, contrairement aux OS Unix.

Je pense que le problème n'est pas chez Windows mais plutôt chez les developpeurs qui ne savent pas comprendre la doc (ou qui ne la lise pas).

Si on regarde la fonction CreateFile() qui doit être relativement bas niveau dans l'API de gestion de fichiers, le 3eme paramètre est justement un flag qui spécifie le mode et le comportement du partage.

Je n'ai malheureusement pas la possibilité de modifier le programme d'écriture.

Dommage ...

La seule solution qu'on m'a soufflé est d'utiliser le Windows Volume Shadow Service pour être capable de copier log.txt et de lire la copie avec 2.exe, ce qui ne me satisfait pas car l'étape de copie prend de plus en plus de temps au fur et à mesure que le fichier log.txt grossi.

Je pensais à utiliser une architecture réseau pour permettre la lecture et l'écriture du fichier par un système unix. Est-ce possible faire ce type d'architecture sur un portable sans connexion réseau physique ?

Une autre idée est de rediriger le fichier vers une entrée d'un autre process, capable de dupliquer les données entre un enregistrement et une routine de traitement. Existe-il un soft ou connaissez vous un exemple de source qui permet de le faire ?

J'ai peur que toutes ces solutions soient un peu bancales

[Mac LAK]

Je pense que le problème n'est pas chez Windows mais plutôt chez les developpeurs qui ne savent pas comprendre la doc (ou qui ne la lise pas).

Oui, c'est hélas un peu trop courant en dév Win32, la plupart ne savent même pas quelles sont les "bonnes pratiques" à appliquer malgré le fait que Microsoft les donne à chaque version d'OS...

J'ai peur que toutes ces solutions soient un peu bancales

Moi, je n'en ai pas peur, j'en suis certain. C'est l'application créant ce fichier qui est mal fichue à la base, et quoi que tu fasses en bidouille là-dessus, tu n'as aucune garantie : tu risques de corrompre le fichier (le drame pour un fichier de log), ou que ça ne fonctionne que par miracle (et que ça cesse de fonctionner au premier KB / SP déployé).

[alpha35]

Merci pour vos réponses, je suis tout à fait d'accord avec vous, ce serait mieux que le soft initial soit bien pensé... mais ce n'est pas le cas.

J'essaie de creuser les redirection de fichiers... Connaissez vous un outil qui monte un disque X: qui est en fait un tampon mémoire utilisable par une autre appli ?

[bacelar]

Franchement, je pense qu'un petit coup de reverse-engineering pour modifier le flag dans la primitive de création du fichier de log sera plus rapide à faire que de passer par des moyens détournés. Si vous avez un minimum de compétences dans le sujet ou un peu de motivation cela va s'en dire. (Et aussi avoir la joie d'envoyer la version patchée du programme à ces GROS guignols).

Avec un peu de chance, ce sont des guignols feignants et ils ont utilisés une librairie de log toute faite (donc ou elle est bien pourrie ou ils s'en servent n'importe comment), et là, vous n'avez qu'à chercher sur le Net une éventuelle méthode "documentée" pour contourner ce problème.

[Médinoc]

D'un autre côté, la plupart du temps, quand on ouvre un fichier en écriture, il ne faut pas que d'autres processus le lisent ou ils risquent d'être surpris. C'est juste que les fichiers de log sont un cas spécial...

[alpha35]

Franchement, je pense qu'un petit coup de reverse-engineering pour modifier le flag dans la primitive de création du fichier de log sera plus rapide à faire que de passer par des moyens détournés. Si vous avez un minimum de compétences dans le sujet ou un peu de motivation cela va s'en dire. (Et aussi avoir la joie d'envoyer la version patchée du programme à ces GROS guignols).

oui, mais cela ne m'arrange pas trop : je ne peux pas modifier le programme vu que c'est un soft commercial, je serais hors la loi...

[Mac LAK]

oui, mais cela ne m'arrange pas trop : je ne peux pas modifier le programme vu que c'est un soft commercial, je serais hors la loi...

En théorie, oui. Toutefois, dans ce cas précis, tu as deux solutions réellement fiables :

• Gueuler auprès de l'éditeur pour qu'ils t'envoient une version acceptant la lecture simultanée du fichier de log.
  Car autant Médinoc à raison à 200% sur les fichiers "normaux" qu'il ne faut JAMAIS lire pendant leur écriture, autant les fichiers de log DOIVENT pouvoir être consultés sans fermer l'application. C'est donc une faute primaire de l'éditeur.
• Chercher l'appel à CreateFile dans le fichier binaire, repérer l'argument correspondant au mode d'ouverture, et patcher sa valeur directement dans le fichier .EXE (4 octets maximum à modifier).
  C'est certes théoriquement illégal, mais en pratique, c'est le seul moyen (sauf MAJ de la part de l'éditeur) pour assurer une fonction qui devrait déjà être présente dès le départ.

De plus, tu as effectivement la licence d'utilisation de ce logiciel, et tu ne vas pas en diffuser une version craquée, ni permettre non plus une fonction qui à l'origine serait réservée à une version supérieure du logiciel, n'est-ce pas ?

Donc, même si tu enfreins la lettre de la loi (enfin, de la licence surtout), l'esprit ne l'est pas. Tu ne fais pas ça pour avoir des avantages indûs, ni pour léser l'éditeur d'une licence. Tu le fais pour contourner un bug bloquant qui n'aurait jamais dû être présent, et en plus tu ne diffuses pas le patch en question...

A ta place, je ferais les deux actions : remontée à l'éditeur, et patch du binaire.

[alpha35]

Merci, mais mon honnêteté m'interdit de le faire...!

Est-ce qu'il existe un moyen sous windows de rediriger un enregistrement dans un fichier vers l'entrée standard d'un process ? Il existe peut-être le moyen de faire un hook système sur l'appel d'écriture ?

[bacelar]

Je ne sais pas si la loi a changé depuis mais durant mes études (~15ans) le reverse-engineering était autorisé en Europe pour compatibilité si le soft avais plus de 5 ans.

[Médinoc]

Le principe d'interopérabilité a... fluctué à l'époque du vote de DADVSI. Il avait été révoqué par la loi elle-même, puis a été rétabli quelques années plus tard par (si je me souviens bien) le conseil d'état.

[Mac LAK]

Merci, mais mon honnêteté m'interdit de le faire...!

Là, ce n'est plus de l'honnêteté, tu sais... Si tu es bloqué, tu es bloqué, c'est tout, et il faut agir en conséquence.

Est-ce qu'il existe un moyen sous windows de rediriger un enregistrement dans un fichier vers l'entrée standard d'un process ? Il existe peut-être le moyen de faire un hook système sur l'appel d'écriture ?

Pas à ma connaissance en tout cas, du moins pas tel que tu l'entends... Et ça ne changera pas grand-chose : ton processus continuera d'utiliser le fichier en accès exclusif, donc il faudrait truander à un niveau en dessous (genre filesystem simulé), ce qui est loin d'être évident.

[alpha35]

Bon, j'ai fait la modif de flag dans le code compilé du programme initial. Un petit changement de registre mis sur la pile et le tour est joué. Ca marche très bien du coup.

Merci à Jenna qui a tout de suite vu la cause du problème et à vous tous pour vos réponses.

Le coup du filesysteme simulé n'est pas idiot, je pense qu'on pourrait utiliser les mêmes techniques de base que FreeOTFE ou TrueCrypt qui créent un disque virtuel pour une sous couche de traitement en parallèle (encryption dans le cas de ces softs)...

[Mac LAK]

Le coup du filesysteme simulé n'est pas idiot, je pense qu'on pourrait utiliser les mêmes techniques de base que FreeOTFE ou TrueCrypt qui créent un disque virtuel pour une sous couche de traitement en parallèle (encryption dans le cas de ces softs)...

Je n'ai pas dit que c'était idiot : j'ai dit que c'était loin d'être évident (sous-entendu "à faire"). Nuance...

[alpha35]

Je n'ai pas dit que c'était idiot : j'ai dit que c'était loin d'être évident (sous-entendu "à faire"). Nuance...

C'était une façon de parler ! Je veux dire que c'est une bonne idée, que je vais creuser dès que j'ai un moment...