Discussion :

[Marie_]

Bonjour,

Tout d'abord je vous averti que je ne suis pas développeuse C, je bidouille en VB, c'est tout. Je n'ai pas vraiment l'intention de commencer un apprentissage en C non plus car ce n'est "normalement" pas mon job...sauf si ...

J'ai plusieurs version d'un éxécutable :
- des anciennes qui marchent très bien et dont les sources n'existent plus
- une nouvelle qui marche moyen et dont j'ai les sources.

Le problème se situ au niveau de la décompression d'un fichier. Le programme cré une chaîne de caractère représentant la commande et la met dans un fichier CMD puis lance le CMD. Dans les versions anciennes et dans la nouvelle la ligne de commande est la même, en voici un exemple :

d:\unzip.exe -p d:\fichier.ZIP > d:\fichier.EXP & echo > d:\FINZIP

Avec les anciennes versions, tout va bien avec la nouvelle la décompression ne se fait pas à cause d'un Warning sur le TimeZone. Voici le message si je lance le CMD dans une fenêtre DOS :

Warning: TZ environment variable not found, cannot use UTC times!!

Après recherche j'ai défini manuellement TZ à NFT-1DFT sur le serveur et tout fonctionne.

Le programme n'est pas sensé être dépendant de cet élément extérieur et on me demande de rétablir la situation...
Comme Zorro n'est pas arrivé et que le C me dépasse complètement, je vous le demande : comment faire pour se passer du TZ ?

Quelques informations sur l'environnement : Windows Server 2003 SE - Visual C++ 6.0 et j'ai vu des includes time.h et timeb.h avec un fichier qui existe dans le bon répertoire, il n'y a de toute façon pas d'alerte ou d'erreur à la compile.

Un extrait du code (évidement, je ne peux pas tout mettre...)

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
	/*<5>* jlv: création de la commande */
	sprintf( fichierFin, "%s\\FINZIP", pdiDefImport->szRepExe);
	sprintf(command,"%s\\unzip.exe -p %s > %s\\%s & echo > %s",
		pdiDefImport->szRepExe, 
		pdiDefImport->szFichImport,
		pdiDefImport->szRepImport,
		pdiDefImport->szDecompressedFile,
		fichierFin );
 
	/*<5>* jlv: écriture de la commande dans un fichier de commande */
	sprintf(strCommandFileName, "%s\\%s.cmd", pdiDefImport->szRepExe, DECOMP);
	unlink(strCommandFileName);
	FCommand = fopen(strCommandFileName, "w");

Voilà, je vous remercie de toutes vos suggestions
(Si votre suggestion est de regarder les tutos merci d'être assez précis car je me vois pas me taper tous les tutos du site en ne sachant pas quoi chercher... )

Marie

[metagoto]

Et si tu rajoutes la var TZ au début du batch ?

Code :

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

sprintf(command,"@set TZ=NFT-1DFT & %s\\unzip.exe -p %s > %s\\%s & echo > %s",

Certes, il faut que command soit assez grand pour recevoir ces extra chars.

[Marie_]

Merci de ta réponse.

C'est une solution de repli qu'on m'avait suggéré (merci pour la syntaxe )

Cependant, comme les fichiers commande des 2 versions sont identiques ce n'est pas la solution d'origine. (Je sais bien qu'on se saura jamais ce que c'était...)

Si quelqu'un à une idée pour s'approcher d'avantage du mode de fonctionnement de l'ancienne version je suis preneuse.
(oui oui, je crois au papa noël)

[metagoto]

C'est bien unzip.exe qui provoque ce warning, non ?

Apparemment, le batch généré est le même suivant les 2 versions du prog.
Donc, heu, tu dois avoir un warning dans les 2 cas, non ? (quand tu testes sur la même machine)

Un warning qui fait que la décompression ne se fait pas, c'est normal ? Y a pas un autre problème ailleurs ?

[Marie_]

C'est bien unzip.exe qui provoque ce warning, non ?

je lance le fichier commande à la mano j'ai le warning donc ce message est généré par l'unzip.
A la mano, la décompression se fait.

Apparemment, le batch généré est le même suivant les 2 versions du prog.
Donc, heu, tu dois avoir un warning dans les 2 cas, non ? (quand tu testes sur la même machine)

Je sais pas bien vu que je vois pas l'erreur quand je lance par l'exe...
Mais il me semble logique effectivement que j'ai l'erreur avec l'ancienne et la nouvelle version et que l'ancienne ne se bloque pas.

Un warning qui fait que la décompression ne se fait pas, c'est normal ?

heu ? tu veux dire "est-ce que c'est normal qu'un simple warning bloque tout ?" la réponse et non

Y a pas un autre problème ailleurs ?

C'est la même machine donc ras côté environnement
Les autres éléments de l'appli n'ont pas subis de modif (fichiers de param, unzip.exe, ...)
Alors, ailleurs peut-être, mais je vois pas où...

Je me demande s'il n'y a pas un truc dans le prog qui bloque l'unzip, mais y a rien de transandant dans la fonction de décompression car ensuite : il lance le fichier cmd, vérifie son spawn, attend un délai de 2sec pour vérifier si finzip a été créé sinon il attend à nouveau jusqu'à échéance du délai et renseigne la log genre : OK ou délai dépassé ou pb spawn.

Pour info : let's go home

Merci a toi
(J'ai pris un peu de temps à te répondre car j'ai retester quelques manips pour être sur...)

[metagoto]

Donc tout ça nous fait penser que le prob est en amont du unzip, dans le nouveau programme. Le warning ne change rien.

Est-ce que le nouveau prog exécute bien la batch ?

il lance le fichier cmd, vérifie son spawn, attend un délai de 2sec pour vérifier si finzip a été créé sinon il attend à nouveau jusqu'à échéance du délai et renseigne la log genre : OK ou délai dépassé ou pb spawn.

Y a quoi dans les logs ?
Bref, c'est pas dit du tout que le nouveau prog en C fasse correctement son job...
Va falloir étudier ça sérieusement

(J'ai pris un peu de temps à te répondre car j'ai retester quelques manips pour être sur...)

No probo