Discussion :

[theawe]

Bonjour,

J'ai développé une architecture Client/Serveur de transferts de fichiers, grosso modo. Lorsque le client reçoit les données envoyées par le serveur, un fichier est ouvert en écriture. Pour ouvrir ce fichier, je passe par la classe ofstream. Un problème survient lorsque le client ferme ce fichier via la méthode close() : Il semblerait qu'il s'agisse en fait d'une exception. J'ai tenté un try{}catch{}, mais je n'ai pas réussi à relever cette exception, le code à l'intérieur du catch{} n'ayant pas été lu (?).

Ce qui me dérange, c'est que cela semble survenir aléatoirement :

• Lorsque j'exécute l'application sans le mode débogage
• Lorsque le client effectue sa deuxième demande de transfert : Lors de la première demande, tout se déroule bien... je n'ai pas de rapport de Visual Studio (VS). Lors de la seconde demande de transfert concernant le même fichier, l'application plante. VS désigne une exception win32 non gérée.

Je ne comprends pas vraiment ce qui cloche. Je ne déclare qu'une fois mon ofstream, l'ouvre et le referme quand il le faut... conditions sans lesquelles, aucun essai n'aurait le résultat escompté. Ce comportement m'échappe vraiment.

Auriez-vous quelque(s) suggestion(s) ?

Il semblerait que le même soucis survienne avec l'utilisation de FILE *, toujours au moment de la fermeture du fichier (fclose()). Le problème me parait complètement bizarre, d'autant plus qu'il arrive vraiment trop aléatoirement maintenant : au premier transfert, ou au second, ou au troisième, ou...
Je n'arrive pas à attraper l'exception. Le débogueur m'indique une "violation d'accès lors de la lecture". Je ne vois pas de quoi il s'agit, et surtout je ne vois pas pourquoi ça marcherait parfois seulement...

[Médinoc]

Une exception Win32 n'est pas nécessairement une exception C++ (même si la réciproque est vraie sous Visual), et n'est donc (normalement) pas interceptée par un try/catch.

Pour le reste, on ne peut pas trop t'aider sans le code.

[theawe]

J'ai deux types de traitement d'écriture dans des fichiers. Je me sers d'ofstream pour le premier, qui correspond à une écriture binaire. Le second fait appel à FILE* pour une écriture en texte.

J'ai une boucle d'écoute dans laquelle j'ai développé les processus d'écriture. C'est donc dans cette boucle que je vais utiliser ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
ofstream of;
FILE * pFile;

Les déclarations sont faites en dehors de la boucle. A l'intérieur de la boucle, j'ouvre ou créer les fichiers un à un, et les remplis séquentiellement.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
//nomFichier est de type const char*
of.open(nomFichier, ios::out | ios::binary);
pFile = fopen(nomFichier, "w");

Je ne les ouvre pas en même temps, je m'y prend comme ceci (je passe sur la réception des données dont j'ai besoin) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
SI typeFichier est binaire
     of.open(nomFichier, ios::out | ios::binary);
     SI tailleFichier > 0
          TQ nombreOctetsRec < tailleFichier
               /* ... Traitement de réception
                       et d'écriture dans le fichier ... */
          FTQ
     FSI
     of.close();
FSI

Je fais exactement la même chose avec FILE*.

A chaque fois que le problème est survenu, cela venait de of.close() ou bien de fclose(pFile).

[Médinoc]

Je sais que si fopen() a échoué, il ne faut pas faire de fclose().
Mais pourquoi ne pas utiliser un ofstream texte pour le second fichier ?

[theawe]

Je sais que si fopen() a échoué, il ne faut pas faire de fclose().

Je n'ai pas eu de rapport d'erreur ciblant fopen(). J'ai tenté ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
pFIle = fopen(nomFichier, "w");
if(pFile != NULL)
{
     /* ... Traitements ... */
}
else AfxMessageBox("/* rapport d'erreur*/");

L'application n'a jamais affiché le rapport d'erreur au cours de mes différents tests.

Mais pourquoi ne pas utiliser un ofstream texte pour le second fichier ?

J'avais utilisé un ofstream au départ mais même avec un buffer bien initialisé, j'avais une taille de fichier, au niveau du client, qui ne correspondait pas à la taille de fichier au niveau du serveur. J'avais initialisé le buffer avant chaque réception d'un bloc de données, mais le problème persistait.

[Médinoc]

Entre un poste Unix et un poste Windows, tu n'es pas censé avoir la même taille lors d'un transfert texte (genre FTP en mode ASCII).
Seul un transfert binaire est supposé donner deux fichiers identiques.

[theawe]

Bonjour,

Le problème persiste ce matin. Je ne vois vraiment pas ce qui cloche...

Rappel du problème : Une exception win32 survient lorsque je fais appel à fclose() ou close() de fstream. Le débogueur m'indique qu'à ce moment précis du code, je viole un accès en lecture mais très franchement, je ne vois pas comment.
Lorsque j'exécute l'application en mode débogage, tout se passe très bien. Aucune exception, aucun problème de fermeture d'un quelconque fichier...

Auriez-vous quelques idées ?
D'avance merci.

[theawe]

Après plusieurs tests et manipulations du code, il semble que le phénomène est très clairement aléatoire... Cela ne marche pas parfois seulement : C'est à devenir dingue, tout simplement.

Lorsque l'appel à fclose() ou à close() génère une exception, le contenu du fichier a auparavant été correctement rempli.

Je pense avoir tenté tout ce que je pouvais, dans les limites des bornes de connaissances qui sont les miennes.

Quelles raisons pourraient empêcher le bon déroulement de la fermeture d'un fichier ?

[ram-0000]

Peut être que le problèmle est ailleurs et que ton exception n'en est que le révélateur.

Peut être des buffer dans lesquels tu écris trop loin et cela met à mal les structures gérées par le noyau et cela se voit à la fermeture du fichier.

Il va falloir chercher, regarder le code, utiliser un truc genre valgrind ou purify pour en être sûr.