Discussion :

[tarsonis753]

Bonjour à tous !
J'ai un petit problème dans mon programme, assez facile à résoudre, mais je ne comprends pas pourquoi !

Il est composé de plusieurs fonctions. Hier, j'ai ajouté la prise en charge des arguments ( int main(int argc, char *argv[]) au lieu de int main(); )
Or, pour tester la boucle d'affichage des arguments, j'ai fait un petit programme à part :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
#include <stdio.h>
int main(int argc, char *argv[])
{
    int i;
    for (i=0; i < argc; i++)
    {
        printf("Argument %i : %s \n", i, argv[i]);
    }
    getch();
    return 0;
}

Dev c++ indique une erreur sur getch();
après plusieurs recherches, j'ai vu qu'il fallait inclure <conio.h>
Effectivement, ça fonctionne à merveille !

Cependant, dans mon gros programme initial qui utilise et abuse du getch(), il n'y a pas de <conio.h>, pourtant, il fonctionne aussi !
Je me dis : peut être que getch() est aussi définie dans un autre header...

Mais quand je copie tous les INCLUDES du gros vers le petit programme (stdlib.h stdio.h math.h io.h fcntl.h string.h), même problème, Dev écrit un truc du genre 'undeclared'.
Je n'ai pas rédigé d'autre fonction getch() dans mon programme, alors, est-ce un bug du compilateur ? Dans un gros programme, est-ce qu'une déclaration peut être implicite ? Bref, qu'est ce qui explique cette incohérence ?!

Mon second problème vient d'une fonction du programme.
En gros, j'ai construit une structure Fichier, comprenant le chemin et le nom du fichier, ainsi qu'une fonction qui prend en paramètre cette structure (1) et une chaîne de caractères.

Elle crée un fichier, l'ouvre (en binaire) et écrit la chaîne dedans.
Avant, on saisissait toutes les informations du fichier dans une fonction de saisie, on appelle (1), et ça fonctionnait à merveille!

Maintenant, je construit un fichier avec les arguments de main (après bien entendu un bricolage et une extraction des chaînes de caractères), l'affichage du nom, prénom est correct, mais la fonction crée un fichier en lecture seule !, donc le programme plante sur ma fonction d'écriture !!

Pourquoi ya a t-il une différence de traitement de cette fonction alors qu'à priori le fonctionnement est similaire ???
Je tourne vraiment en rond et ça devient presque lourd !
Est-ce que quelqu'un peut m'aider ????????????????
Merci d'avance !!!

[Melem]

getch, qui n'est pas une fonction standard, retourne un int et donc il est possible de ne pas le déclarer (car on peut ne pas déclarer une fonction qui retorune un int, mais selon les réglages le compilateur peut être plus strict). Pour ton problème de fichier il nous faut ton code pour voir ce qui ne va pas.

[tarsonis753]

merci pour le getch !
le code pour le fichier est :

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
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
typedef struct
{
	unsigned char chemin[C];	/* chemin d'accès*/ /
	unsigned char nom[C];		/* nom = 241 + 3 ext */
	short int h;				/* handle */
	unsigned long int taille;	/* taille du fichier en octets */
} Fichier;
 
int main(int argc, char *argv[])
{
 
       strcpy(destination.chemin,"k:\\"); 
       strcpy(destination.nom,"crypt.tmp"); 
 
 
     if (clairtocrypt(destination)==0)
     {....................
 
 
 
short int clairtocrypt (Fichier Destination)
 
{
    printf("Ouverture des fichiers\n");
    strcat(Destination.chemin,Destination.nom);
    creationfichier(Destination.chemin); /* fichier vide qui sera la destination */
    Destination.h=open (Destination.chemin, O_RDWR |O_BINARY);
	if (verifieouverturefichier(Destination)==0)
	{
		Destination.taille=512;
	}
	else... :aie:
 
 
short int verifieouverturefichier(Fichier verif)
{
	if (verif.h == -1)
	{
		printf("Erreur d'ouverture du fichier : %s\n", verif.chemin);
	    return(-1);
	}
	else
	{
		printf("Ouverture de: %s :\tREUSSIE\n", verif.chemin);
	    return(0);
	}
}
 
short int creationfichier(unsigned char* srcfile)
{
    Fichier cree;
    cree.h=open (srcfile, O_CREAT);:evilred::evilred::evilred::evilred::evilred:
    close (cree.h);
return 0;
}

Et donc le problème, c'est qu'avec un appel de la fonction clairtocrypt en temps normal (une fonction où on saisit les infos au clavier (saisiefichier(void)), le fichier est crée en mode normal, alors que ici, avec le même code, les mêmes chemin et nom, et le même appel, l'attribut est lecture seule !

le problème se situe bien ici, car j'ai mi un getch() dans clairtocrypt juste après la création du fichier pour pouvoir modifier l'attribut avec l'onglet "propriétés" de zindow$, et ça remarche.

Y a t-il un bug ? ou plus bourrin, y a t-il une fonction en C (car mon projet ne doit pas utiliser C++) qui annule cet attribut ??????
Merci d'avance pour toute aide !!

[Médinoc]

Quand on utilise la fonction non-standard open() au lieu de la fonction standard fopen(), il faut explicitement spécifier les droits en troisième paramètre si on utilise le flag O_CREATE.

Sous POSIX, ils s'expriment sous la forme de droits Unix, donc typiquement un nombre en octal (0777 pour donner les tous droits à tout le monde sur le fichier)

[nicolas.sitbon]

il est possible de ne pas le déclarer (car on peut ne pas déclarer une fonction qui retorune un int, mais selon les réglages le compilateur peut être plus strict).

ça reste déconseillé étant donné que cela reste permis en C99 mais risque de ne plus l'être dans les prochaines normes. Mieux vaut tout de suite prendre les bonnes habitudes.
Cordialement.

[tarsonis753]

Merci pour cette réponse rapide ! ça marche enfin !!!!
Et donc pour les droits, est-ce que je mets :

cree.h=open (srcfile, O_CREAT, 0777) ??

avec un 'zéro' pour Octal ? quels sont les autres attributs octals ?

Merci pour tout, car ça m'ôte une énorme épine du pied ! (et du prog...)

[Emmanuel Delahaye]

Et donc pour les droits, est-ce que je mets :

cree.h=open (srcfile, O_CREAT, O777) ??

Pourquoi open() ? C'est pas standard... Qu'est-ce qui ne va pas avec fopen() ?

avec un 'zéro' pour Octal ?

Dans ce cas, c'est 0777 et non O777 ...

quels sont les autres attributs octals ?

Définit 'attributs'.

Doucement avec les smileys, ça me soule...

[tarsonis753]

Salut à tous !
Au début de la discussion, j'avais créé un programme qui utilisait la fonction open pour manipuler les fichiers.
Je trouvais plusieurs avantages à cela : sobre, clair, mode binaire.

Depuis, j'ai réalisé un programme qui ouvre un fichier, lit certaines données et les modifie selon plusieurs paramètres.

Cela peut s'apparenter à un programme qui ouvre un fichier où est stockée une playliste par exemple, lit les fichiers dans la liste, leur Hash, vérifie s'ils sont disponibles sur le DD et enlève les occurences désuettes (exemple pour simplifier).

Le problème est que l'on me demande de convertir mes fonctions "open" en "fopen". Je suis d'accords, mais dans le code simplifié suivant :


-------

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
 
if ( (fich=fopen (chemin, "wb+")) == NULL)
{
   	fprintf(stderr,"Impossible d'ouvrir le fichier données\n");
	free(ligne);
   	getch();
	return(1);
}
 
printf("Ouverture du ficher : %s\n",chemin);
 
fseek (fich , 0 , SEEK_END);    /*Trouver la taille du fichier*/
taille = ftell (fich);
rewind (fich);
 
printf("\nAccompli : taille du fichier : %d ",taille);

-----------

Je me retrouve devant le fait qu'il n'existe apparemment pas de fonction qui donne la taille du fichier directement (comme filelenght() avec open). Ce n'est pas très grave.

Mais surtout, je n'arrive pas à créer un mode parmi :
/*
"r" ouverture d'un fichier texte en lecture.
"w" ouverture d'un fichier texte en écriture.
"a" ouverture d'un fichier texte en écriture à la fin.
"rb" ouverture d'un fichier binaire en lecture.
"wb" ouverture d'un fichier binaire en écriture.
"ab" ouverture d'un fichier binaire en écriture à la fin.
"r+" ouverture d'un fichier texte en lecture/écriture.
"w+" ouverture d'un fichier texte en lecture/écriture.
"a+" ouverture d'un fichier texte en lecture/écriture à la fin.
"r+b" ou "rb+ ouverture d'un fichier binaire en lecture/écriture.
"w+b" ou "wb+ ouverture d'un fichier binaire en lecture/écriture.
"a+b" ou "ab+ ouverture d'un fichier binaire en lecture/écriture à la fin.
*/

qui me permette de "mettre à jour mon fichier".

j'ai lu sur un autre forum que "wb+" le faisait, mais cela ne fonctionne pas ici, sous KDE, ce mode écrase irrémédiablement le fichier.
Le mode append me permet pas de modifier le milieu du fichier.

La solution que je vois proposée serait de créer un fichier temporaire, mixer dedans mes données, supprimer la source et renommer le fichier temporaire.

Cependant, mon programme doit manipuler des fichiers de plusieurs GigaOctets, donc :

->Existe-t-il un mode me permettant juste de modifier les données à l'intérieur d'un fichier avec fopen ?

-> Puis-je avoir la taille autrement (sans les API windows) ?

-> Est-il préférable de conserver open ?

Merci pour toute aide !
PS : désolé pour la longueur un peu barbare du message, mais je souhaitais poser la question aussi précisément que possible.

[Médinoc]

Si "w+b" ne marche pas, alors "r+b" devrait marcher. La différence, si je me souviens bien, c'est que "r+b" ne crée pas le fichier quand il n'existe pas.

[tarsonis753]

merci pour une réponse aussi rapide,
j'ai trouvé une partie du problème, c'était le nom du fichier, sous zindows, je peux manupuler des fichiers sans extensions, pas avec ce programme sous linux. (mon fichier "essai" était écrasé avec l'attribut "r" de fopen", mais pas "essai.txt").
Ensuite, c'est effectivement "r+b" pour ouvrir un fichier en binaire pour le modifier.
Merci pour tout !!!!!!!!!!!!

[Emmanuel Delahaye]

même en ouvrant mon fichier en lecture ("r"), en utilisant juste le code pour connaitre sa taille :

Code :

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

1
2
3
4
 
fseek (Lu.fich , 0 , SEEK_END);    /*Trouver la taille*/
Lu.taille = ftell (Lu.fich);
rewind (Lu.fich);

le fichier est effacé....
une idée ?

C'est pas possible. Le problème est ailleurs.

Montre ton code exact qui produit ce défaut.