Raison pour echec d'un remove

Bonjour,
Je travaille sur un projet qui tourne sous VMS, unix, NT.
Sous Unix, il semble qu'un fichier ne soit pas supprimé, j'aimerai en connaitre la raison.
Voici le code de la fonction de suppression

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

int f_supprimer_fichier(char * const nom_fichier_a_supprimer ) { int retour; #ifndef V_UNIX char nom_fichier[1024]; strcpy(nom_fichier,nom_fichier_a_supprimer); strcat(nom_fichier,";*"); retour=remove(nom_fichier); #else retour=remove(nom_fichier_a_supprimer); #endif return retour; }

---

En principe dans le cas posant problème on a V_UNIX positionné.
Pour information sous VMS les fichiers sont versionné, et ont un nom du type Nom_fichier;version. Quand on fait un delete nom_fichier;* on supprime toutes les versions du fichier, d'où la concaténation.

La question principale est peut-on savoir pourquoi le remove n'a pas renvoyé 0, de préférence quelque soit la plateforme.
Merci
Soazig

Citation:

---

Envoyé par soazig

La question principale est peut-on savoir pourquoi le remove n'a pas renvoyé 0, de préférence quelque soit la plateforme.

---

errno contient le code de l'erreur quand remove retourne -1:

Citation:

---

EFAULT
pathname pointe en dehors de l'espace d'adressage accessible.
EACCES
L'écriture dans le répertoire contenant pathname n'est pas autorisée pour l'UID effectif du processus, ou l'un des répertoires de pathname ne permet pas la recherche (exécution).
EPERM
Le répertoire contenant pathname à son Sticky-Bit (S_ISVTX) positionné, et l'UID effectif du processus n'est ni l'UID du fichier, ni celui du répertoire le contenant.
ENAMETOOLONG
pathname est trop long.
ENOENT
Un répertoire contenu dans pathname n'existe pas, ou est un lien symbolique pointant nulle part.
ENOTDIR
Un composant de pathname n'est pas un répertoire.
ENOMEM
Pas assez de mémoire pour le noyau.
EROFS
pathname est situé sur un système de fichiers en lecture seule.

---

Hello,

Citation:

---

Envoyé par soazig

Bonjour,
Je travaille sur un projet qui tourne sous VMS, unix, NT.
Sous Unix, il semble qu'un fichier ne soit pas supprimé, j'aimerai en connaitre la raison.
Voici le code de la fonction de suppression

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

int f_supprimer_fichier(char * const nom_fichier_a_supprimer ) { int retour; #ifndef V_UNIX char nom_fichier[1024]; strcpy(nom_fichier,nom_fichier_a_supprimer); strcat(nom_fichier,";*"); retour=remove(nom_fichier); #else retour=remove(nom_fichier_a_supprimer); #endif return retour; }

---

En principe dans le cas posant problème on a V_UNIX positionné.
Pour information sous VMS les fichiers sont versionné, et ont un nom du type Nom_fichier;version. Quand on fait un delete nom_fichier;* on supprime toutes les versions du fichier, d'où la concaténation.

La question principale est peut-on savoir pourquoi le remove n'a pas renvoyé 0, de préférence quelque soit la plateforme.
Merci
Soazig

---

As-tu une documentation de remove() avec des particularités pour ta plate-forme ? Car si remove() ne renvoie pas 0, la variable globale errno est positionnée à un certain code d'erreur. Je n'ai pas la norme C sous la main, mais avec un man remove sur ton système tu devrais avoir les codes d'erreur que peut prendre errno (un EACCESS peut-être). Mais pour cela il faut inclure <errno.h> et tester la variable errno.

A+
Foobar1329

On peut aussi inclure:

Code:

---

1 2	#include <string.h> /* strerror() */

---

afin d'utiliser la fonction strerror() qui permet de connaître la signification textuelle d'une valeur de errno.

Code:

---

1 2	printf("Origine de l'erreur: %s.\n",strerror(errno));

---

;)

Oui, ou utiliser perror() :

Code:

---

1 2	#include <stdio.h> void perror (const char *s);

---

qui est encore plus simple :

Code:

---

perror("Origine de l'erreur");

---

Citation:

---

Envoyé par zooro

Oui, ou utiliser perror() qui est encore plus simple

---

Oui c'est clair! ;)

Rebonjour, et merci
Comme il n'y a pas de redirection du canal d'erreur standard dans mon environnement, le perror ne pourra pas être utilisé, en tout cas pas sous VMS.
Voilà comment je compte m'y prendre
Dans ma fonction je renvoie le errno, comme ça il n'est pas perdu

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

int f_supprimer_fichier(char * const nom_fichier_a_supprimer ) { int retour; #ifndef V_UNIX char nom_fichier[1024]; strcpy(nom_fichier,nom_fichier_a_supprimer); strcat(nom_fichier,";*"); retour=remove(nom_fichier); #else retour=remove(nom_fichier_a_supprimer); #endif if (retour!=0) { retour=errno; } return retour; }

---

Et dans l'appelant je le récupère, quelque chose comme ça

Code:

---

1 2 3 4 5 6

retour_supr= f_supprimer_fichier(nom_fichier); if (retour_supr!0); { tracer_chaine("erreur dans la suppresion du fichier", strerror(retour_supr); }

---

Sachant que tracer_chaine est la fonction qui me permet d'alimenter le fichier trace de l'application.

Qu'en pensez-vous?

Vu que le problème est surtout sur unix, et qu'en principe je développe sous vms, je dois attendre qu'un collègue se libère pour tester tout cela.
Je vous tiens au courant dès que c'est testé.

Merci encore.
Soazig

Citation:

---

Envoyé par soazig

Comme il n'y a pas de redirection du canal d'erreur standard dans mon environnement, le perror ne pourra pas être utilisé, en tout cas pas sous VMS.

---

Il me semble que le flux de sortie d'erreur est toujours disponible, non ? Au pire, il sera identique au flux de sortie standard.

Bonjour,

Citation:

---

Envoyé par zooro

Il me semble que le flux de sortie d'erreur est toujours disponible, non ? Au pire, il sera identique au flux de sortie standard.

---

Il ne s'agit pas d'une application console et honnetement je ne sais pas dérouter le flux de sortie d'erreur dans une transaction appelée par moniteur transactionnel ACMS sous VMS à partir d'un client windows.
Vu que je peux m'en passer je ne vois pas pourquoi je chercherai 10 h pour le faire.
Merci
Soazig

Coucou,
Vous allez rire tellement c'est énorme le define V_UNIX n'était pas défini dans cette portion de code! Et unix n'aime pas la suppression du fichier toto.fic;*
Il a mauvais gout!

Je me suis posée la question en postant le code hier, et je me suis dit qu'il était défini.
Conclusion, je n'ai eu à faire aucune des suggestions.
A+
Soazig

Citation:

---

Envoyé par soazig

Vous allez rire tellement c'est énorme le define V_UNIX n'était pas défini dans cette portion de code!

---

Petite astuce pour savoir si une zone de compilation conditionnelle est active : placer (provisoirement) un piege :

Code:

---

#error

---

et recompiler. Si l'erreur se produit à la compilation, c'est que la zone est active.