Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Existence d'un fichier
Bonjour,
J'ai un petit problème avec la gestion des fichiers. En fait j'aimerais savoir si mon fichier est toujours présent sur le disque pour être sur que l'écriture va pouvoir être possible.
A l'ouverture (avec fopen) le fichier est bien créé. Ensuite je le supprime à la main et j'exécute fputs. Ce dernier ne retourne pas d'erreur.
Comment faire pour savoir si le fichier existe toujours sur le disque ? (afin de le recréer si besoin)
Merci
J'ai rien compris. Si tu veux créer un fichier, tu l'ouvres en mode "w". Si il n'y a pas d'erreur et qu'il existe, il est détruit. Dans tous les cas un nouveau fichier est crée.Envoyé par nico_n
Effectivement fopen crée mon fichier. C'est pas ce que je voulais dire, alors je vais essayer d'être plus clair.
Donc j'exécute fopen avec a+ dans mon cas, et le fichier est bien créé. Ensuite je supprime le fichier à la main (clic droit supprimer), pendant que mon logiciel tourne toujours. Le tout pour simuler un cas qui pourrait arriver lors de son utilisation.
Donc après l'avoir supprimer, j'exécute une commande qui va essayer d'écrire avec fputs. Or même si le fichier n'existe plus, fputs ne retourne pas d'erreur, fflush non plus.
Y a t'il un moyen de savoir si le fichier est bien toujours là ? Ou est-ce que dois le fermer le le réouvrir à chaque fois (fopen, fputs, fclose) ?
Sauf que ça va le faire beaucoup de fois (peut être même vraiment beaucoup de fois).
Si tu travailles sur un système POSIX (généralement sous Unix), il y a stat() pour faire toutes sortes de tests sur des fichiers.
Cependant, si tu effaces un fichier ouvert en lecture ou en écriture, celui-ci continue d'exister sur le disque jusqu'à la fermeture du dernier handler. Si tu recrées un autre fichier portant le même nom alors que le premier est toujours ouvert quelque part, tu créeras deux fichiers différents (le premier étant voué à disparaître).
Note: Dans le cas présent, on dit handle, pas handler.
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
Bonjour,
Merci beaucoup pour votre réponse. Je développe mon appli sous Mac OS X, mais elle sera amenée à être recompilée et utilisée sous Linux et Windows.
Donc si une solution est compatible avec les 3 systèmes c'est mieux, sinon je suis près à adapter certaine partie du code pour que ça fonctionne.
En tout cas je vais regarder la fonction stat()
Merci
stat() ne convient pas à ce que tu veux faire, puisque tu peux toujours supprimer le fichier entre le stat() et le write().
Je pense que la seule façon de faire est effectivement de re-ouvrir le fichier (freopen). Note que pour détecter le cas ou le fichier a été supprimé, "a+" ne convient pas puisque ça recréra un fichier vide sans lever d'erreur. Il faudrait plutôt "r+" (a tester).
une autre solution (si tu as les droits) serait de modifier temporairement les droits d'accès.
Mais es-tu sûr que puts ne génère pas d'erreur ? et fprintf ??
ça m'étonne...
En fait ça m'étonnait aussi, mais j'ai fais le test et effectivement aucune erreur n'est levée, ni sur le fwrite si sur le fclose qui suit. Les données sont juste écrites "dans le vide".
Edit : en fait le coup de réouvrir le fichier ne marche pas mieux que le stat(), puisque le fichier peut être supprimé entre sa réouverture et l'écriture.
C'est normal: Une fois le fichier ouvert, plus de vérifs.
Si tu cherches à supprimer un fichier ouvert, il n'y a habituellement que deux effets possibles:
- Tu reçois une erreur en tentant de supprimer (échec)
- Le fichier est supprimé dès sa fermeture (réussite)
En gros, tu n'écris pas "dans le vide" (le fichier est toujours là) mais c'est tout comme (et je pense que tu ne peux plus le réouvrir une fois qu'il est pseudo-supprimé).
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
autre solution (mais là on commence à compliquer) :
faire un timer et aller vérifier régulièrement gràce à un stat.
Mais fondamentalement je crois que notre ami a mal posé son problème...
Nous aurions tous déjà rencontré le problème...
Non, il n'est plus là. Le rm supprime bien le fichier. On ne le voit plus sur disque. Néamoins les écritures sur le fd qui avait été crée quand le fichier existait encore continuent de marcher... On a dont bien en un sens des écritures "dans le vide".
En fait, je pense qu'on ne le voit plus dans le dossier. Mais il y a de fortes chances pour qu'il soit toujours physiquement présent sur le disque (voir on inode et ses blocs de données).
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
La question est : pourquoi as-tu besoin de vérifier ce cas ? Comme je te l'ai dit, le fichier, même s'il n'est plus référencé dans le répertoire, continue d'exister jusqu'à ce que le dernier handle qui le concerne soit libéré. Il est donc normal que les fonctions de lecture ou d'écriture continuent à fonctionner normalement.
Si tu mets des contrôles explicites dans ton programme, tu vas contourner le fonctionnement normal du système et l'utilisateur ou l'administrateur qui le géreront risquent de s'arracher les cheveux à comprendre d'où vient le comportement anormal.
C'est bien le cas, et c'est nécessaire car, s'il y a des processus rédacteurs et d'autres lecteurs, le fichier doit continuer à agir de façon habituelle. Il suffit de faire deux programmes « lire.c » et « ecrire.c » pour s'en convaincre. Après suppression manuelle du fichier, un petit lsof sur le numéro d'inode du fichier montre les choses de façon claire :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
Ça cause souvent du tracas aux admins systèmes qui ont une trop haute opinion d'eux-mêmes (dédicace à celui de mon ancienne compagnie) et qui, lorsque qu'un programme qui devient fou remplit un fichier temporaire et que le contenu de /tmp a été nettoyé depuis le lancement du programme, voient leur disque se remplir de manière inexpliquée jusqu'à saturation. Quand c'est moins rapide, on commence par constater une différence entre du et df que l'on attribue à l'espace reservé à root et à la granularité des blocs alloués ... avant que le phénomène n'empire.
si c'est juste pour verifier comment l'application se comporte en cas de suppression de fichier, le mieux reste de gerer ce cas pour qu'il ne se produit pas (sinon tu as ta reponse avec les handle). Un système de lock file http://en.wikipedia.org/wiki/File_locking est facile a mettre en place....
Le problème c'est que sous unixoïdes en tout cas, il n'est pas possible de vraiment locker un fichier. Les "file locks" sont simplement "advisory" : il servent à gérer les conflits entres le programmes qui le veulent bien, pas à empécher toute opération extérieure sur un fichier.
Une autre option (la plus safe à mon avis) est d'écrire dans un fichier temporaire (dans /tmp) : copier le fichier original à cet endroit, avec un nom généré (tmpnam ou tempname) , lui ajouter ce qu'on veut, et le recopier à l'endroit original.
Comme ça, même si l'original est détruit, on s'en fiche..
Merci beaucoup pour vos réponses.
J'ai essayer la fonction stat(...), et ça fonctionne (en tout cas sous Mac OS X).
Après suppression du fichier, st_dev (device inode resides on) est à 0. Dans les autres cas il est supérieur à 0.
Je peux donc faire fclose, puis de nouveau un fopen uniquement en cas de suppression (pas à chaque fois).
Il faut quand même que je fasse le test sous les autres OS
Sous Linux, au moins, on peut activer les mandatory locks avec l'option mand au montage du filesystem. Les verrous deviennent alors incontournables.
Répondre avec citation
Partager