tester si un fichier est vide

tester si un fichier est vide - C - Programmation

Marsh Posté le 04-04-2006 à 11:45:29    

Bonjour,
Je voudrais tester si un fichier est vide (auquel cas je l'effacerai avec la fonction remove). Comment puis-je faire cela sans trop de lignes de code?
J'ai pensé à ouvrir le fichier (qui contient du code ASCII) et tester si la lecture de la première ligne est égale à " " mais je ne suis pas très sûre...
Merci d'avance!
Sandra

Reply

Marsh Posté le 04-04-2006 à 11:45:29   

Reply

Marsh Posté le 04-04-2006 à 11:52:16    

ou en testant sa taille.
 
Cela dit l'ouvrir et en récuperer des caractères n'est pas une mauvaise idée.

Reply

Marsh Posté le 04-04-2006 à 12:35:16    

Ce que tu peus faire c'est utiliser la fonction fseek, qui permet d'ouvrir un fichier en positionnant ton curseur ou tu veus, si l'indice de début "SEEK_SET" est le même que l'indice de fin "SEEK_END", alors tu peus considérer  que le fichier est vide. Je pense que ça peut marcher comme ça.
 
je te conseil un man fseek pour plus de détail

Message cité 1 fois
Message édité par doudoudetahiti le 04-04-2006 à 12:36:22
Reply

Marsh Posté le 04-04-2006 à 12:36:18    

Ce que tu peus faire c'est utiliser la fonction fseek, qui permet d'ouvrir un fichier en positionnant ton curseur ou tu veus, si l'indice de début "SEEK_SET" est le même que l'indice de début "SEEK_END", alors tu peus considérer comme le fichier vide. Je pense que ça peut marcher comme ça.
 
je te conseil un man fseek pour plus de détail

Reply

Marsh Posté le 04-04-2006 à 12:56:38    

Pour le fun, tu peux aussi utiliser la fonction stat(), qui renseigne une structure "struct stat", structure qui contient entre autres choses le champ st_size (taille en bytes du fichier).
 
Je dis "pour le fun" parce que c'est une fonction POSIX, donc pas forcément disponible sur ton système d'exploitation (mais vu que c'est P90 il y a de grandes chances pour que tu l'aies... mais gaffe à la portabilité).

Reply

Marsh Posté le 04-04-2006 à 12:58:09    

Tente de faire une lecture dedans, si tu es à eof c'est qu'il est vide.


Message édité par LePhasme le 04-04-2006 à 12:58:30
Reply

Marsh Posté le 04-04-2006 à 13:06:26    

fopen("toto","r" )
fseek(f, SEEK_END)
ftell(f)
fclose()
ftell renvoie la longueur du fichier.

Message cité 1 fois
Message édité par Trap D le 04-04-2006 à 13:06:52
Reply

Marsh Posté le 04-04-2006 à 13:10:35    

Trap D a écrit :

fopen("toto","r" )
fseek(f, SEEK_END)
ftell(f)
fclose()
ftell renvoie la longueur du fichier.


 
C'est effectivement la plus portable des solutions.
 
Pour utiliser stat() (j'insiste, c'est POSIX, donc "plus ou moins portable" => méfiance) :
 
struct stat machin;
stat("chemin/vers/mon/fichier", &machin);
/* => machin.st_size contient la taille du fichier */
 

Reply

Marsh Posté le 04-04-2006 à 13:13:47    

Merci beaucoup pour tous vos conseils!

Reply

Marsh Posté le 04-04-2006 à 14:55:58    

doudoudetahiti a écrit :

Ce que tu peus faire c'est utiliser la fonction fseek, qui permet d'ouvrir un fichier en positionnant ton curseur ou tu veus, si l'indice de début "SEEK_SET" est le même que l'indice de fin "SEEK_END", alors tu peus considérer  que le fichier est vide. Je pense que ça peut marcher comme ça.


et ftell()...
 
En mode texte uniquement. En mode binaire, le résultat est indéterminé.


Message édité par Emmanuel Delahaye le 04-04-2006 à 14:56:29

---------------
Des infos sur la programmation et le langage C: http://www.bien-programmer.fr Pas de Wi-Fi à la maison : http://www.cpl-france.org/
Reply

Marsh Posté le 04-04-2006 à 14:55:58   

Reply

Marsh Posté le 28-06-2012 à 16:23:38    

voici la syntaxe:  
 
FILE * f=fopen(SANDER,"r" );
fseek(f,0,SEEK_END);  
long lfile=ftell(f);   //longueur du fichier  
if(lfile2==0) ...
fclose(f);

Reply

Marsh Posté le 28-06-2012 à 16:27:18    

voici la syntaxe:
 
FILE * f=fopen(SANDER,"r" );
fseek(f,0,SEEK_END);  
long lfile=ftell(f);   //longueur du fichier  
if(lfile==0)...
fclose(f);


Message édité par belbah le 28-06-2012 à 16:27:51
Reply

Marsh Posté le 28-06-2012 à 16:28:51    

merci de répondre à ce topic vieux de 6 ans. Qui plus est, cette technique pose problème avec des fichiers de plus de 4Go ...
La meilleure façon reste encore de faire avec ce que l'OS propose.


---------------
last.fm
Reply

Marsh Posté le 25-07-2012 à 09:47:41    

theshockwave a écrit :

merci de répondre à ce topic vieux de 6 ans. Qui plus est, cette technique pose problème avec des fichiers de plus de 4Go ...
La meilleure façon reste encore de faire avec ce que l'OS propose.


 
Non, pas si tu utilises size_t au lieu de long comme variable résultat du ftell  :jap:  
 
Et un compilateur qui date pas de la dernière guerre...

Message cité 1 fois
Message édité par edwoud le 25-07-2012 à 09:47:59
Reply

Marsh Posté le 25-07-2012 à 11:05:14    

edwoud a écrit :


 
Non, pas si tu utilises size_t au lieu de long comme variable résultat du ftell  :jap:  
 
Et un compilateur qui date pas de la dernière guerre...


 
You, sir, missed the point : sur une plateforme 32 bits, ton size_t (comme un long int) fait 32 bits, donc ton fichier de 4Go te pose toujours un souci ... Après, l'API définit que ftell retourne un long int, sous windows en x64, un long int fait toujours 32 bits. Même si tu stockes le résultat dans un size_t (qui cette fois-ci, est bien 64 bits), tu auras une valeur tronquée, donc tu l'auras dans l'os.


---------------
last.fm
Reply

Marsh Posté le 25-07-2012 à 11:06:59    

Mais c'est pas techniquement possible de lire un fichier de plus de 4go sur un 32bits ? Sans découpage :D


---------------
Perhaps you don't deserve to breathe
Reply

Marsh Posté le 25-07-2012 à 11:24:35    

Terminapor a écrit :

Mais c'est pas techniquement possible de lire un fichier de plus de 4go sur un 32bits ? Sans découpage :D


 
bah, tu peux pas le stocker entièrement en mémoire, non, t'as pas un espace d'adressage suffisant. Cela dit, rien ne t'empêche de le processer à la volée. C'est rarement une bonne chose que de se balader dans le fichier à coups de ftell et fseek "absolus".


---------------
last.fm
Reply

Marsh Posté le 25-07-2012 à 11:29:58    

http://www.unix.org/version2/whatsnew/lfs.html
 
(Pour le probleme initial, je tenterais simplement de lire un byte et je ne m'amuserais pas avec fseek, ftell etc).


---------------
The truth is rarely pure and never simple (Oscar Wilde)
Reply

Marsh Posté le 25-07-2012 à 14:44:33    

theshockwave a écrit :


 
You, sir, missed the point : sur une plateforme 32 bits, ton size_t (comme un long int) fait 32 bits, donc ton fichier de 4Go te pose toujours un souci ... Après, l'API définit que ftell retourne un long int, sous windows en x64, un long int fait toujours 32 bits. Même si tu stockes le résultat dans un size_t (qui cette fois-ci, est bien 64 bits), tu auras une valeur tronquée, donc tu l'auras dans l'os.


 
Effectivement, je me suis laissé abuser. On peut les lire mais avoir leur taille, c'est plus casse-couille...
 
Si je regarde (sous windows) les .h, la position dans le fichier est bien un 64bits (fpos_t) -> __int64
 
il faudrait utiliser fgetpos pour avoir la bonne valeur mais c'est sûrement pas portable
 
si je regarde sous un linux 32 bits, ça m'a l'air transparent via un jeu de #define -> __USE_LARGEFILE64
 
Mais si je teste sous linux32, j'ai un segfault lors du ftell  :D  (bordel!)
 
Faudrait passer par ftello64 sur linux (en 32 bits)
 
rien de portable en somme...

Message cité 2 fois
Message édité par edwoud le 25-07-2012 à 14:53:57
Reply

Marsh Posté le 25-07-2012 à 16:13:49    

edwoud a écrit :


 
Effectivement, je me suis laissé abuser. On peut les lire mais avoir leur taille, c'est plus casse-couille...
 
Si je regarde (sous windows) les .h, la position dans le fichier est bien un 64bits (fpos_t) -> __int64
 
il faudrait utiliser fgetpos pour avoir la bonne valeur mais c'est sûrement pas portable
 
si je regarde sous un linux 32 bits, ça m'a l'air transparent via un jeu de #define -> __USE_LARGEFILE64
 
Mais si je teste sous linux32, j'ai un segfault lors du ftell  :D  (bordel!)
 
Faudrait passer par ftello64 sur linux (en 32 bits)
 
rien de portable en somme...


 
 :jap: exact. D'où ma recommandation d'aller voir ce que propose l'OS pour ce genre de choses :)


---------------
last.fm
Reply

Marsh Posté le 26-07-2012 à 09:20:13    

edwoud a écrit :


 
Effectivement, je me suis laissé abuser. On peut les lire mais avoir leur taille, c'est plus casse-couille...
 
Si je regarde (sous windows) les .h, la position dans le fichier est bien un 64bits (fpos_t) -> __int64
 
il faudrait utiliser fgetpos pour avoir la bonne valeur mais c'est sûrement pas portable
 
si je regarde sous un linux 32 bits, ça m'a l'air transparent via un jeu de #define -> __USE_LARGEFILE64
 
Mais si je teste sous linux32, j'ai un segfault lors du ftell  :D  (bordel!)
 
Faudrait passer par ftello64 sur linux (en 32 bits)
 
rien de portable en somme...


 
C'est plutôt ça qu'il faut mettre  : -D_FILE_OFFSET_BITS=64

Reply

Marsh Posté le 26-07-2012 à 09:23:03    

xilebo a écrit :


 
C'est plutôt ça qu'il faut mettre  : -D_FILE_OFFSET_BITS=64


 
 :jap:  

Reply

Marsh Posté le 26-07-2012 à 11:53:19    

Sous Windows, il faut utiliser la structure __stat64 et les fonctions associées (_fstat64), pour les fs admettant des fichiers de taille supérieure à  2Go.
C'est pas nouveau, vu que ça date de Win98.
L'équivalent unix (stat64 et fstat64 est par contre maintenant "deprecated" )
A+,


Message édité par gilou le 26-07-2012 à 11:56:50

---------------
There's more than what can be linked! --    Iyashikei Anime Forever!    --  AngularJS c'est un framework d'engulé!  --
Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed