Test Fichier Vide

Version imprimable

22/11/2008, 14h27
mdabire

Test Fichier Vide

Bonjour tout le monde

Voilà ça deux jour que je cherche une façon simple 1 à 2 ligne maximum
pour tester si un fichier, est vide ( pas NULL, existe mais ne contient aucun caractère ) ou non.

j'ai reussi à le faire mais il me coute en lignes, et il est spécifique à mon problème
j'aimerai beaucoup faire mieux, et surtout qu'il soit faisable avec
n'importe qu'elle type de fichier. si un test simple existe,
je serai heureux de le connaître.
Merci.
22/11/2008, 14h45
Invité(e)
Bonjour,

Le plus simple faisable est à mon avis :
1. Ouvrir le fichier (fopen)
2. Se déplacer à la fin d-dit fichier (fseek)
3. Regarder la position du curseur (ftell)
4. fermer le fichier (fclose)
Après, les différents systèmes qui existent peuvent avoir des fonctions toutes faites qui font ce que tu demandes, mais on sort du standard. Ex : GetFileSize de Win32.
22/11/2008, 14h59
Obsidian

Citation:

Envoyé par mabu

Après, les différents systèmes qui existent peuvent avoir des fonctions toutes faites qui font ce que tu demandes, mais on sort du standard. Ex : GetFileSize de Win32.

Et stat() (et dérivés) sous UNIX et systèmes conformes POSIX-2001. À elles deux, ces fonctions devraient déjà couvrir la majorité des cas.
22/11/2008, 16h00
ram-0000

+1 pour stat()

Tu peux aussi ouvrir ton fichier, tenter de lire et vérifier si cela échoue

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
/*
 * IN  : Nom du fichier
 * OUT : 1 - Fichier Vide
 *       0 - Fichier Non Vide ou Erreur 
 */
int fempty(char const *fname) 
{
	FILE *fdesc = fopen(fname,"r");
	int ret = 0;
 
	if( fdesc )
	{
		(void)fgetc(fdesc);
		if( feof(fdesc) )
		{
			ret = 1;
		}
		fclose(fdesc);
	}
	return ret;
}

Ce n'est pas en deux lignes mais c'est simple :)

22/11/2008, 16h46
Obsidian

Citation:

Envoyé par ssmario2

Tu peux aussi ouvrir ton fichier, tenter de lire et vérifier si cela échoue

À ce compte-là, je préfère encore la méthode de mabu ... :-)

Citation:

Ce n'est pas en deux lignes mais c'est simple :)

Mais s'il lui prend l'envie d'ouvrir un fichier non régulier (le port série, par exemple), le programme n'échouera pas mais attendra indéfiniment.
22/11/2008, 17h06
ram-0000

Le problème d'ouvrir (en lecture) le fichier et de tenter de lire un octet pour savoir s'il est vide est que outre le fait déjà signalé des devices (/dev/ttyS0 par exemple), si on n'a pas le droit sur le fichier, l'ouverture va échouer et risque de signaler le fichier comme vide alors que ce n'est pas le cas.

Par exemple, sur un système *Nix, le fichier /etc/shadow ne peut être lu par le quidam moyen (droit de lecture seulement pour root) par contre, sa taille peut être lue par tout le monde (droit de lecture pour tout le monde sur le répertoire /etc)

De plus, une ouverture puis lecture puis fermeture de fichier, c'est un peu plus lourd en consommation de ressource que de demander sa taille au système.

Donc, je confirme : +2 pour stat()
22/11/2008, 17h55
Obsidian

Citation:

Envoyé par ram-0000

Le problème d'ouvrir (en lecture) le fichier et de tenter de lire un octet pour savoir s'il est vide est que outre le fait déjà signalé des devices (/dev/ttyS0 par exemple), si on n'a pas le droit sur le fichier, l'ouverture va échouer et risque de signaler le fichier comme vide alors que ce n'est pas le cas.

Oui, mais son code teste l'ouverture correcte du fichier. Cela dit, le problème reste entier car comme l'information ne peut être vérifié, il y a une chance sur deux que le code de retour soit le bon ... ou le mauvais :-)
22/11/2008, 19h45
orfix

Citation:

Envoyé par Obsidian

À ce compte-là, je préfère encore la méthode de mabu ... :-)

Pourquoi cette préférence ? d'autant plus que fseek n'a pas bonne réputation notamment pour les déplacemets en fin de fichier :

Citation:

Envoyé par ISO/IEC 9899:TC3

§7.19.3
234) Setting the file position indicator to end-of-file, as with fseek(file, 0, SEEK_END), has
undefined behavior for a binary stream (because of possible trailing null characters) or for any stream
with state-dependent encoding that does not assuredly end in the initial shift state.

Citation:

Envoyé par ram-0000

De plus, une ouverture puis lecture puis fermeture de fichier, c'est un peu plus lourd en consommation de ressource que de demander sa taille au système.

Généralement quand on cherche à savoir ce genre d'informations c'est pour utiliser le dit fichier non ?
donc stat+ouverture+traitement+fermeture face à ouverture+traitement+fermeture.
une simple constatation ...

Une méthode portable et simple, mais limitée.
Une méthode efficace, mais pas portable.

au PO de faire un choix.
22/11/2008, 20h56
Obsidian

Citation:

Envoyé par ssmario2

Pourquoi cette préférence ?

Ben, la réponse est dans les posts précédents :

- Sémantiquement, le système ne peut pas savoir ce que tu cherches à faire, alors qu'il existe des fonctions pour le faire ;

- Ouvrir un fichier a un coût, spécialement si son support n'est pas un disque dur, où s'il est partagé à travers le réseau. Or, la majorité de l'overhead lors d'un appel à un fichier se fait en début de fonction, à l'ouverture en à la lecture. C'est flagrant quand on utilise une disquette, par exemple.

- Si tu n'as pas le droit d'ouverture sur le fichier, ta fonction ne peut pas s'exécuter correctement ;

- Si ton fichier n'est pas un fichier régulier, mais un tube, un socket, une door Solaris, ou un fichier spécial, au mieux ta fonction échoue ;

- Au pire, si tu lis COM1 ou /dev/ttyS0, par exemple, tu lis un flux et la ta fonction fait un appel bloquant : elle va attendre indéfiniment un caractère qui n'arriv era jamais et ton programme va rester bloqué ;

- Même si tu connais à l'avance le nom de ton fichier (ce qui restreint de beaucoup l'intérêt de ta fonction), tu n'es pas à l'abri qu'un lien symbolique le renvoie vers un autre fichier, de n'importe quel type cette fois ;

- Tous les fichiers ne sont pas en accès aléatoire, notamment quand ils sont stockés sur bande. Dans la majorité des cas, il suffit de consulter la TOC du support concerné pour connaître sa taille ;

- Ouvrir un fichier implique parfois la pose d'un verrou qui peut empêcher un autre programme de fonctionner. À contrario, si un autre programme a fait une ouverture exclusive, ça peut, encore une fois, empêcher ta routine de fonctionner, et lui faire renvoyer un code invalide ;

- Lire un fichier spécial peut affecter son contenu (générateur aléatoire, ou de numéro de série unique, etc.) ;

Pour être sûr de ne jamais rencontrer ces problèmes, il faudrait soit se cantonner à un système où il ne se présente jamais et, dans ce cas, on oublie la portabilité et on utilise les fonctions du système, soit vérifier à l'avance le type du fichier, ce qui compliquerait encore ta fonction et qui n'est de toutes façons pas faisable en C standard.

Question subsidiaire : quelle fonction utilise-t-on pour connaître le type d'un fichier ? :-)

Citation:

d'autant plus que fseek n'a pas bonne réputation notamment pour les déplacemets en fin de fichier :

C'est une note de bas de page qui se réfère à un paragraphe traitant des wide-oriented text and binary streams. Elle précise qu'un fichier n'a pas besoin de se terminer dans l'état d'alignement initial et que par conséquent, il peut traîner quelques zéros en fin de ficher même dans un flux binaire.

Ce n'est pas appliquable si le fichier n'a pas été ouvert dans ce genre de mode et dans tous les cas, ça nous renseigne quand même sur ce que l'on veut savoir : même si ce sont des résidus, le fichier n'est pas vide.

Citation:

Généralement quand on cherche à savoir ce genre d'informations c'est pour utiliser le dit fichier non ? donc stat+ouverture+traitement+fermeture face à ouverture+traitement+fermeture.
une simple constatation ...

Pas forcément. Ça peut servir à les supprimer, par exemple. Un fichier vide peut être aussi un témoin, ou un fichier de lock.

Alors effectivement, on peut se passer d'un stat() ou d'un GetFileSize() si on a l'intention de le lire tout de suite après : l'échec de la lecture suffit à nous faire prendre une décision pour la suite, quelqu'en soit la cause. Mais, dans ce cas, on ne fait pas une fonction spéciale qui ouvre un fichier, lit un seul caractère, et le referme tout de suite après.

Citation:

Une méthode portable et simple, mais limitée.
Une méthode efficace, mais pas portable.

Objectivement, on a vu pourquoi une lecture de caractère n'est pas portable, et un bête stat() reste quand même plus simple que d'écrire une fonction et d'ouvrir un fichier. Et comme stat() est POSIX 2001, si tu tombes sur un système qui ne gère ni GetFileSize() (Windows) ni stat(), alors il faudra te pencher plus avant sur le système exotique que tu utilises. :-)
22/11/2008, 22h14
orfix

Je comprends mieux maintenant, c'est bien plus compliqué que ce que je pensais. :aie:

quand j'ai dit :

Citation:

Envoyé par ssmario2

Pourquoi cette préférence ?

c'était par rapport à la méthode de mabu, est non au stat.

Merci en tout cas pour ces éclaircissements !
22/11/2008, 23h14
Obsidian

Citation:

Envoyé par ssmario2

Merci en tout cas pour ces éclaircissements !

You're welcome.