Discussion :

[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 :

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

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

[homeostasie]

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:

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.

[Foobar1329]

Hello,

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 :

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

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

[homeostasie]

On peut aussi inclure:

Code :

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

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 :

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

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

[zooro]

Oui, ou utiliser perror() :

Code :

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

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

qui est encore plus simple :

Code :

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

perror("Origine de l'erreur");

[homeostasie]

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

Oui c'est clair!

[soazig]

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 :

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

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 :

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

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

[zooro]

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.

[soazig]

Bonjour,

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

[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

[Emmanuel Delahaye]

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 :

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

#error

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