Acces en lecture à un fichier verrouillé pour écriture (en c++ sous windows XP)

Version imprimable

01/12/2009, 20h23
alpha35

[Résolu] Acces en lecture à un fichier verrouillé pour écriture (en c++ sous windows XP)

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.
02/12/2009, 08h48
Jenna

Citation:

Envoyé par alpha35

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.

Citation:

Envoyé par alpha35

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

Dommage ...

Citation:

Envoyé par alpha35

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
02/12/2009, 13h40
Mac LAK

Citation:

Envoyé par Jenna

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

Citation:

Envoyé par Jenna

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é).
02/12/2009, 21h05
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 ?
02/12/2009, 22h00
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.
02/12/2009, 22h43
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...
03/12/2009, 08h03
alpha35

Citation:

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...:cry:
03/12/2009, 10h42
Mac LAK
Citation:

Envoyé par alpha35

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

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.
05/12/2009, 13h43
alpha35

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

Est-ce qu'il existe un moyen sous windows de rediriger un enregistrement dans un fichier vers l'entrée standard d'un process ? :oops: Il existe peut-être le moyen de faire un hook système sur l'appel d'écriture ?
07/12/2009, 01h58
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.:aie:
07/12/2009, 09h27
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.
07/12/2009, 10h17
Mac LAK

Citation:

Envoyé par alpha35

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

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.

Citation:

Envoyé par alpha35

Est-ce qu'il existe un moyen sous windows de rediriger un enregistrement dans un fichier vers l'entrée standard d'un process ? :oops: 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.
08/12/2009, 20h07
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)...
09/12/2009, 09h52
Mac LAK

Citation:

Envoyé par alpha35

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... ;)
09/12/2009, 21h12
alpha35

Citation:

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