Discussion :

[GuiYom00]

Bonjour a tous,

Voila j'ai une petite question concernant la gestion des fichiers de "grande taille" et ce qu'il en est au niveau du C Ansi.

Si je ne me trompes pas, la taille maximale possible pour un fichier dépend du système de fichier utilisé.
Supposons que mon DD soit en Fat32 (ici au moins je suis sur de la limite a 2Go).

Je fais un programme qui se déroule de la sorte
1-creation d'un fichier
2-tant que une condition n'est pas vérifiée, ecriture de données dans le fichier avec fwrite
3-fermeture du fichier

Je me demandais donc comment "sécuriser" mon code pour que, par exemple il s'arrête lorsque la quantité de données écrites a atteint la limite du système de fichier.

Merci d'avance et bonne journée,
G.

[ram-0000]

Je me demandais donc comment "sécuriser" mon code pour que, par exemple il s'arrête lorsque la quantité de données écrites a atteint la limite du système de fichier

Peut être en testant la valeur retournée par fwrite()

Return Value
The total number of elements successfully written is returned as a size_t object, which is an integral data type. If this number differs from the count parameter, it indicates an error.

[GuiYom00]

Je pensais aussi a ca, mais dans ce cas est il possible de faire une difference entre par exemple un disque plein et un cas ou la taille maximale est atteinte?

Remarque je pourrai utiliser une fonction qui permet d'estimer la taille actuelle du fichier et essayer de "deduire" de cela la cause de l'erreur mais si il y a plus "propre" je suis preneur

[Melem]

Je pensais aussi a ca, mais dans ce cas est il possible de faire une difference entre par exemple un disque plein et un cas ou la taille maximale est atteinte?

Pourquoi faire? Que feras-tu dans l'un ou dans l'autre cas? Il n'y a pas de meilleure solution portable que ce que ram_0000 t'as dit. Tout ce que tu peux faire c'est informer l'utilisateur de la cause de l'erreur, avec perror par exemple.

Remarque je pourrai utiliser une fonction qui permet d'estimer la taille actuelle du fichier et essayer de "deduire" de cela la cause de l'erreur ...

Ah oui? et comment? En supposant que lorsqu'il y a erreur par exemple alors qu'on n'a pas atteint la limite alors c'est que le disque est plein? Au fait en parlant de limite, y a pas de fonction standard qui permet de la connaître ...

Supposons que mon DD soit en FAT32 (ici au moins je suis sur de la limite a 2Go)

4Go.

[GuiYom00]

Pourquoi faire? Que feras-tu dans l'un ou dans l'autre cas? Il n'y a pas de meilleure solution portable que ce que ram_0000 t'as dit. Tout ce que tu peux faire c'est informer l'utilisateur de la cause de l'erreur, avec perror par exemple.

Voila en fait ce que je voudrais faire :
Si fwrite renvoie 0 a cause du disque plein
alors : arrêt du programme en informant l'utilisateur
Si fwrite renvoie 0 car le fichier est trop gros
alors : création d'un nouveau fichier pour continuer les enregistrements

La aussi pour "identifier" l'erreur je peux tenter de créer un nouveau fichier en inscrivant 1octet dedans,
si fwrite renvoie 1 => j'etais bien en taille limite de fichier
si fwrite renvoie 0 =>arret du programme et informer l'utilisateur l'erreur était "autre"

Ah oui? et comment? En supposant que lorsqu'il y a erreur par exemple alors qu'on n'a pas atteint la limite alors c'est que le disque est plein? Au fait en parlant de limite, y a pas de fonction standard qui permet de la connaitre ...
4Go.

Oups pour les 2Go au lieu de 4Go j'etais mal reveillé moi :S
Ensuite pour connaitre la taille du fichier etant donné qu'il s'agit de fichiers binaires, il y a la fonction proposée dans la FAQ C par ex
http://c.developpez.com/faq/?page=fi...HIERS_filesize

[Melem]

Voila en fait ce que je voudrais faire :
Si fwrite renvoie 0 a cause du disque plein
alors : arrêt du programme en informant l'utilisateur
Si fwrite renvoie 0 car le fichier est trop gros
alors : création d'un nouveau fichier pour continuer les enregistrements

fwrite ne retourne pas forcément 0 lorsqu'ily a une erreur. Lis bien la doc de cette fonction. On ne peut pas connaître de manière portable si un disque est plein ou non. De même il n'y a pas de fonction portable qui permette de conaître la taille limite dans le système de fichiers. Même la valeur placée dans errno par une fonction pour indiquer la cause d'une erreur est dépendante (pas à 100% quan même) de l'implémentation ...

La aussi pour "identifier" l'erreur je peux tenter de créer un nouveau fichier en inscrivant 1octet dedans,
si fwrite renvoie 1 => j'etais bien en taille limite de fichier

Comme je l'ai dit, tu vas supposer ... Tout ce que tu peux en déduire d'une manip de ce genre c'est qu'il est possible que ...

Ensuite pour connaitre la taille du fichier etant donné qu'il s'agit de fichiers binaires, il y a la fonction proposée dans la FAQ C par ex

J'ai jamais dit qu'on ne pouvait pas calculer la taille d'un fichier.

[totaliou]

Tu peux verifier la valeur de errno:

Code :

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

1
2
3
4
5
6
7
 
if ((size = fwrite(.......)) == 0)
 if (errno == EFBIG)
   {
       perror("myprog");
       exit(1); 
    }

les codes de errno set par fwrite:
http://www.mkssoftware.com/docs/man3/fwrite.3.asp
Puis si tu ne connais pas errno:
http://www.linux-kheops.com/doc/man/...3/errno.3.html

Globalement c'est pas mal de proteger tous les appels systemes de cette maniere. Utiliser perror permet d'avoir un message explicite "automatiquement" en fonction de la valeur de errno.

[Melem]

Tu peux verifier la valeur de errno:

Code :

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

1
2
3
4
5
6
7
 
if ((size = fwrite(.......)) == 0)
 if (errno == EFBIG)
   {
       perror("myprog");
       exit(1); 
    }

Voilà un bon exemple de code dépendant d'une implémentation (EFBIG). Merci.

[totaliou]

Voilà un bon exemple de code dépendant d'une implémentation (EFBIG). Merci.

Effectivement l'implem. de fwrite n'est pas normalisé à ce niveau. Au temps pour moi. La portabilité.... un vrai problème
Merci.

[Emmanuel Delahaye]

Effectivement l'implem. de fwrite n'est pas normalisé à ce niveau. Au temps pour moi. La portabilité.... un vrai problème
Merci.

Le problème, c'est de ne pas lire les docs de référence...

http://www.opengroup.org/

[totaliou]

Le problème, c'est de pas lire les docs de référence...

http://www.opengroup.org/

Cela reste un problème...
Il y a t-il une doc sur opengroupe.org particulière? C'est un peu déroutant sans recherche spécifique.

[Emmanuel Delahaye]

Cela reste un problème...
Il y a t-il une doc sur opengroupe.org particulière? C'est un peu déroutant sans recherche spécifique.

POSIX.1 tu t'inscris, c'est gratuit, pas de spam.

[GuiYom00]

Désolé de la réponse tardive, je n'ai pas pu me repencher sur ce probleme recement...

Donc merci pour vos réponses et je vais faire avec ces informations pour gerer ca. Je vais faire une version POSIX.1 si présent et dans le non POSIX.1 je pense m'orienter la dessus :
definir une taille maximale de fichier en Mo: 1024Mo par ex
-dans les routines d'ecriture, si taille actuelle+taille nouvel enregistrement <taille maximale, on écrit
-si taille actuelle+taille nouvel enregistrement >taille maximale, on crée un nouveau fichier.
-si le nombre d'éléments écrits par fwrite est différent du nombre d'éléments a écrire =>erreur et arret du programme.
Je sais que ce systeme n'est pas parfait, mais j'essaye de trouver le meilleur compromis pour mon problème, étant donné que ces fichiers peuvent nécessiter facilement plusieurs jours pour etre obtenus.
De plus je possèdes des moyens tiers d'analyse des fichiers en "post-traitement" qui peuvent permettre de vérifier si les données présentes sont cohérentes ou pas



PS : Merci Emmanuel pour les liens sur l'opengroup, je vais garder ca en bookmark