Bonsoir !  
 
Je suis en train de programmer un pseudo-FTP en C.  
 
Pour l'instant tout marche bien : le client peut lancer les commandes put et get, et ça fonctionne.  
Pendant l'exécution, le serveur affiche quelques traces sur la sortie standard (avec printf).  
 
Maintenant je souhaite passer en multi-clients, avec des fork. Tout a l'air de fonctionner correctement, à un détail près : lors d'un put, tout ce que le serveur devrait écrire dans stdout (avec des printf) est écrit dans le fichier ouvert en écriture par le serveur (et qui devrait être l'exacte copie du fichier envoyé par le client) !!! Ainsi si le fichier envoyé par le client contient du texte, les traces du serveur sont mélangées avec le contenu du fichier envoyé. Et bien sûr, rien ne s'affiche sur la sortie standard du serveur.  
Entre l'appel à fork et la création du fichier, rien ne s'affiche, et dès que le fichier est crée, les sorties sont redirigées dans ce fichier. Lorsque le fichier est fermé, rien ne s'affiche à nouveau.  
 
J'aimerais bien savoir par quel prodige la sortie standard est redirigée vers un autre fichier à cause du fork... Et si possible, donnez moi une piste pour me sortir de cet embêtant problème..  
 
Notez que c'est la première fois que j'utilise fork en C, donc je galère un peu.  
 
 
Merci beaucoup pour votre aide !

Au hasard, tu n'utiliserais pas des fonctions comme dup() et dup2() ? Un fork fait hériter les descripteurs de fichiers aux processus fils, sortie standard y compris.

Non je n'utilise pas dup.  
Au moment du fork je ne me sers que d'un seul descripteur de fichier (implicitement) : la sortie standard. J'ai vu pleins d'exemples sur le Web qui utilisent des printf après un fork, et ils ne semblent pas présenter le même problème.  
 
Vu que le père reste reste en écoute d'une connexion, chaque fils n'a la connaissance que d'un seul descripteur de fichier (celui écrit à partir du fichier envoyé par le client). Il ne peut pas y avoir de confusion.. Je ne vois vraiment pas où se trouve le problème.  
A tout hasard, je mets la structure de mon code au niveau du fork, parce que comme la première fois que je l'utilise, je m'y prends peut-être mal..  
 

 
C'est un peu du bricolage, mais je n'ai pas pu inventer quelque chose de mieux...  
 
Je ne sais vraiment pas comment m'en sortir là.. J'ai vraiment peu de temps (je devais rendre ce TP au premier semestre...).  
 
Merci !

Permettez-moi d'upper, parce que je n'ai toujours pas résolu mon mystérieux problème. Je suis clairement dans une impasse là. Je commence à penser à enlever tous les printf et faire comme si tout marchait bien. Mais mes printf sont utiles...

Y a moyen de voir tout le code, si ce n'est pas trop long ?

Bon, le C est définitivement un langage incroyable..  
Pendant quelques jours j'ai commenté tout le code qui concernait le multi-utilisateur, afin d'améliorer mon serveur et de faire quelques tests.  
Eh bien figurez-vous que lorsque j'ai décommenté ces quelques lignes de code, les printf marchaient, comme par enchantement, alors même que je n'ai strictement rien changé (sauf ajouté quelques commentaires).  
Le problème s'est donc résolu tout seul, et mon FTP est près à être rendu.  
 
Ca fera une belle anecdote à raconter à mes enfants quand je serai vieux.  
 
Merci tpierron pour ton aide.

 
Comportement aléatoire : c'est mauvais signe.
Ça ne vient certainement pas du langage, et peu probablement du compilateur.
 
Il y a donc dans ton code, quelque part, un truc qui met le bazar. Très souvent, c'est dû à une erreur dans la gestion de la mémoire.
Passe le code au debugger ou mieux, si tu as accès à ce genre d'outil, fais un audit de code (Purify, Insure++, etc).
 
Bon courage, parce que ce genre d'erreur silencieuse, c'est ce qu'il y a de plus galère à tracer, vu que potentiellement, ça peut se situer pas du tout à l'endroit où l'erreur se produit.

Oui, je pense aussi qu'il y a une erreur, mais impossible à trouver. J'ai fait assez attention pour la gestion de la mémoire, mais il se peut en effet qu'il y ait une coquille.. M'enfin le code est quand même pas super long, et je l'aurais remarqué à force de chercher..  
J'ai eu la flemme d'utiliser un débugger, mais finalement j'aurai dû..  
Bon, le prof qui va corriger ce TP a la même machine que moi et le même OS, et donc certainement le même compilateur. Donc avec un peu de chance il n'aura pas de problème.  
 
D'ailleurs pour la gestion de la mémoire, j'ai été obligé de faire des efforts et j'ai tout revu, parce que j'avais sans cesse des Bus Error aléatoires. Ce genre d'erreur est très chiant à localiser, alors j'ai revu toutes mes chaînes de caractères (entre autres), et j'ai fait quelque chose d'à peu près propre, même s'il est vrai que je ne connais pas la méthode canonique qu'il faut employer.

Quand tu compiles en mode debug (option -g sur gcc), un bus error génère un core dump (fichier core qui traine à l'endroit où tu as exécuté le binaire).
 
Ouvre ton debugger favori avec le binaire, et donne-lui ce fichier core à manger.
Sur gdb, tu tapes simplement "gdb binaire core", tu attends que ça charge, et tu tapes "stack".
Ça te renverra la pile d'appel, et tu sauras alors où le programme a planté.