Accès multiples à un fichier en C++sous window XP

Oui, et si tu fais des ouvertures/fermeture, sous windows, ça va ramer.
Tu peux voir du coté des MMF (Memory Mapped File):
CreateFileMapping(), OpenFileMapping(), MapViewOfFile(), etc.

et en faisant une copie du fichier avant ouverture ?


cricky, je suis assez d'accord, mais il me semble que s'il n'a pas accès au source du programme en amont, ca risque d'être foireux !

Ah oui, je n'avais pas bien lu.  

Du coup, c'est problématique puisque l'OS ajoute les verrous. Tu peux essayer sur une partition FAT32, mais le problème devrait persister.
Je vois juste le service Volume Shadow Copy, qui a été mis en place dans l'OS pour permettre de faire un backup en bloquant les écritures et permettant la lecture des fichiers verrouillés.
Je ne l'ai jamais utilisé, mais je ne vois que cette possibilité propre (je mets évidemment de côtés les hook système).

Bon courage.  
http://msdn.microsoft.com/en-us/library/aa381508%28VS.85%29.aspx
http://msdn.microsoft.com/en-us/library/aa384589%28VS.85%29.aspx

Merci.

Effectivement, même chose avec une partition FAT. Cela semble assez compliqué, je vais me plonger dans le VSC. On peut accéder directement en lecture à la copie fantôme sans avoir à le rercopier (pour gagner du temps   )?

C'est quoi un hook système... ?

Autrement, je me demandais s'il existait un soft qui permet d'installer un système de fichier virtuel dans lequel 1.exe enregistre, mais qui traite le fichier différemment d'un fichier disque. Une sorte de redirection de sortie, transparente pour le programme 1.exe.

Comme je t'ai dit, je n'ai jamais utilisé, donc si ça marche fais le nous savoir.  
Par hook, je voulais dire dévier les appels systèmes, un peu ce que tu proposes mais à l'appel de la fonction, ce qui n'est pas très propre.

essaye quand même de copier le fichier avant d'exploiter, non pas le fichier d'origine, mais sa copie.

Une fois exploité, tu supprime le fichier de travail.

L'OS n'empeche pas (il me semble) de recopier un fichier déjà ouvert par un autre soft!


Sinon, un hook système me parait chaud dans ton cas de figure.

J'ai essayé de copier le fichier en cours d'écriture, mais Windows ne le permet pas. Je crois me souvenir de mes cours d'OS que c'est effectivement un désavantage de Windows que n'ont pas les OS unix. D'où l'idée d'enregistrer dans une partition gérée par un système unix (accès par réseau ou autre...) et de faire une lecture par le même moyen. Comment faire tourner un réseau sur une même machine avec 2 OS différents ?

J'ai laissé tombé le hook système, c'est plus adapté à des évènements souris, clavier, ...

Microsoft a mis en place le Volume Shadow Service pour justement pouvoir faire des backup de serveurs.  

La solution que tu proposes CRicky me semble la plus prometteuse parce qu'elle va marcher, je n'en doute pas.

Elle ne me satisfait pas complètement parce qu'elle implique un temps de traitement qui augmente avec la taille du fichier. Je souhaite faire du temps réel : pendant que 1.exe enregistre (à une cadence de 75 ms), 2.exe doit traiter le flux de données toutes les 10 s pour indiquer lorsque une condition particulière sur ces données est remplie. Si le temps d'attente pour obtenir la condition est de 3 heures, le fichier d'échange a le temps de grossir... et le temps de traitement de 2.exe va devenir pénalisant s'il faut le recopier en totalité toutes les 10 s.

C'est pour cela que je chercher encore une solution alternative qui permet de gérer un flux de taille constante...