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