Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
1544 connectés 

  FORUM HardWare.fr
  Programmation
  C

  [C] Provoquez des IO Error

 


 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

[C] Provoquez des IO Error

n°1196380
mart
Posté le 10-09-2005 à 07:29:31  profilanswer
 

Hello
 
en C est il possible de controler le fait qu'on a bien écrit dans un fichier? en effet j'ai testé avec la valeur de retour de fprintf, valide meme si entre temps j'ai supprimer le fichier.
 
Merci!

mood
Publicité
Posté le 10-09-2005 à 07:29:31  profilanswer
 

n°1196386
olivthill
Posté le 10-09-2005 à 09:01:22  profilanswer
 

:hello:  
En effet, dans certains cas très particuliers, comme tu t'en es aperçu, on peut écrire dans le vide sans s'en rendre compte.
 
C'est pour cela qu'il faudrait toujours vérouiller les fichiers avant d'écrire  dedans sans oublier libérer le fichier après. C'est pour cela que la fonction fopen() est souvent remplacée par d'autres fonctions qui ont des options de vérouillage.
Une autre option, moins bonne, consiste à ne pas vérouiller le fichier, mais à mettre des droits d'accès restrictifs sur le fichier de manière à ne pas autoriser les suppressions et déplacement de fichier par des utilisateurs malveillants ou inconscients du problème.
 
Par ailleurs, il n'est pas interdit de relire ce que l'on a écrit pour être sûr de l'existence des données écrites.

n°1196396
mart
Posté le 10-09-2005 à 09:50:15  profilanswer
 

ok je vais opter pr la soluce de relecture

n°1196401
Emmanuel D​elahaye
C is a sharp tool
Posté le 10-09-2005 à 09:57:36  profilanswer
 

mart a écrit :

en C est il possible de controler le fait qu'on a bien écrit dans un fichier? en effet j'ai testé avec la valeur de retour de fprintf, valide meme si entre temps j'ai supprimer le fichier.


Tu peux aussi tester le code retour de fclose().
 
Le langage C part du principe que le système est mono-processus, mono-tâche. Donc, lorsqu'un fichier est ouvert, il appartient au processus courant, et il ne peut rien arriver.
 
Il est évident qu'en environnement multi-processus, multi-tâche, avec des disques distants, tout peut arriver, et ce de manière asynchrone, vu les différents mécanismes de caches, bufferisation et [pseudo] parralellisation mis en place.
 
Si on cherche une sécurité maximale, il faut des outils de gestion de fichiers sécurisés. Si c'est pour faire une base de donnée, il existe des systèmes portables comme MySQL ou PostgreSQL...


---------------
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/
n°1196564
mart
Posté le 10-09-2005 à 16:13:48  profilanswer
 

très bonne idée le fclose, le prob c'est que le soft doit tourner en boucle (analyseur de log), j'ai des exemples mais j'ai peur que les fichiers soit EXTREMEMENTS longs et donc qu'on ecrive dans le vide pendant un moment
 
Autre question: je viens de faire un test dont le résultat me parait encore plus bizarre: apres que le fichier soit ouvert mais avant d'être lu, je mets un getchar(). Pendant ce temps, je supprime le fichier. Surprise (pour moi), j'appuie sur enter et le fichier est lu correctement! et c'est bien le bon puisque je ne peux pas faire deux fois la meme commande (vu que j'ai supprimé, il  peux pas l'ouvrir...)


Message édité par mart le 10-09-2005 à 16:16:46
n°1196583
mart
Posté le 10-09-2005 à 16:36:23  profilanswer
 

je viens de tester fclose, il retourne 0 meme si le fichier a été supprimer entre tps; Argh.

n°1196585
0x90
Posté le 10-09-2005 à 16:38:07  profilanswer
 

man fclose

Citation :


NOTES
       Note  that fclose only flushes the user space buffers provided by the C
       library. To ensure that the data is physically stored on disk the  ker‐
       nel buffers must be flushed too, e.g. with sync(2) or fsync(2).


 
Use the man luke :o


---------------
Me: Django Localization, Yogo Puzzle, Chrome Grapher, C++ Signals, Brainf*ck.
n°1196596
mart
Posté le 10-09-2005 à 16:56:08  profilanswer
 

okay, oui effectivement. (je fais des man mais je lis pas en entier, juste matter la return value. Ca me parait bien, mais est ce que ca marche sur ts les OS? c'est Conforming to POSIX only...
what about fflush (ANSI)? :)


Message édité par mart le 10-09-2005 à 16:58:42
n°1196600
Emmanuel D​elahaye
C is a sharp tool
Posté le 10-09-2005 à 17:01:59  profilanswer
 

mart a écrit :

okay, oui effectivement. (je fais des man mais je lis pas en entier, juste matter la return value. Ca me parait bien, mais est ce que ca marche sur ts les OS? c'est Conforming to POSIX only...
what about fflush (ANSI)? :)


fclose() appelle déjà fflush(). Mais c'est quoi ton problème exactement, t'es pas un peu parano ?


---------------
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/
n°1196605
mart
Posté le 10-09-2005 à 17:10:58  profilanswer
 

mon probleme est que je dois détecter les erreurs d'écriture sur les fichiers dans lesquels j'écris. Je n'ai trouvé d'autre exemple de simu pr provoquer ces erreurs qu'en supprimant le fichier en cours de route (c'est radical). Pas moyen de détecter cette erreur... fflush, fclose, fsync (quel est ce "int fd" en parametre? pkoi pas FILE * ?), sync, tout parait tjs normal pr le soft

mood
Publicité
Posté le 10-09-2005 à 17:10:58  profilanswer
 

n°1196617
Emmanuel D​elahaye
C is a sharp tool
Posté le 10-09-2005 à 17:22:18  profilanswer
 

mart a écrit :

mon probleme est que je dois détecter les erreurs d'écriture sur les fichiers dans lesquels j'écris. Je n'ai trouvé d'autre exemple de simu pr provoquer ces erreurs qu'en supprimant le fichier en cours de route (c'est radical). Pas moyen de détecter cette erreur... fflush, fclose, fsync, sync, tout parait tjs normal pr le soft


Tu peux tester le code retourné par la fonction d'écriture. Celui-ci indiquera une erreur si , par exemple, le disque est plein (facile à tester sur une clé USB) ou inaccessible (réseau, clé retirée) ou si un secteur est endommagé rendant l'écriture impossible (et encore, je pense plutôt que le secteur est marqué 'défectueux' et qu'un autre est utilisé...). Mais une 'erreur d'écriture', non, ça n'existe pas. Au niveau physique, tout ce qui est enregistré est immédiatement relu pour vérification.
 
Maintenant, si quelqu'un décide d'effacer le fichier qui est en train d'être écrit, c'est soit que le système est mauvais (Sous Windows NT ou Unix/Linux, c'est pas possible), soit qu'il est mal utilisé, et qu'il faut au préalable 'vérrouiller' le fichier. Il y a des fonctions systèmes pour ça, mais c'est pas standard (ça peut être rendu portable par l'utilisation d'une surcouche portable comme la glib).

Citation :

(quel est ce "int fd" en parametre? pkoi pas FILE * ?)


En C standard on utilise un objet opaque de type FILE* pour accéder aux flux. Certaines fonctions systèmes utilsent des 'handlers' (numéros uniques de type int) pour accéder aux périphériques (fichiers ou autres).


Message édité par Emmanuel Delahaye le 10-09-2005 à 17:25:13

---------------
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/
n°1196644
mart
Posté le 10-09-2005 à 18:01:04  profilanswer
 

Le problème étant, je ne peux pas flinguer mon disque dur ou le rendre plein j'avais fait ce test de suppression. Je viens de le remplacer par le l'idée du disque amovible enlevé à l'arrache. fprintf et fwrite renvoie tjs des valeurs comme s'ils écrivaient mais fflush ftell et fclose renvoie -1, bon signe. Je ferais un flush apres chaque fprintf (j'ai deux fonctions d'ecriture pr deux fichiers, dc ce sera pas trop long) et testerai sa valeur. On est ds les normes?

n°1196656
Emmanuel D​elahaye
C is a sharp tool
Posté le 10-09-2005 à 18:09:09  profilanswer
 

mart a écrit :

Le problème étant, je ne peux pas flinguer mon disque dur ou le rendre plein j'avais fait ce test de suppression. Je viens de le remplacer par le l'idée du disque amovible enlevé à l'arrache. fprintf et fwrite renvoie tjs des valeurs comme s'ils écrivaient mais fflush ftell et fclose renvoie -1, bon signe. Je ferais un flush apres chaque fprintf (j'ai deux fonctions d'ecriture pr deux fichiers, dc ce sera pas trop long) et testerai sa valeur. On est ds les normes?


Ca marche. ça va légèrement ralentir (écriture directe plustôt que différée), mais ça devrait aller.


---------------
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/
n°1196701
mart
Posté le 10-09-2005 à 18:42:15  profilanswer
 

Ok, donc on est bon pr l'ecriture. j'ai fait le meme test avec le fichier qui doit etre lu, et la, debrancher un disque dur ne le dérange pas. Il est chargé ou le fichier quand on fopen?

n°1196705
Emmanuel D​elahaye
C is a sharp tool
Posté le 10-09-2005 à 18:48:00  profilanswer
 

mart a écrit :

Ok, donc on est bon pr l'ecriture. j'ai fait le meme test avec le fichier qui doit etre lu, et la, debrancher un disque dur ne le dérange pas. Il est chargé ou le fichier quand on fopen?


Dans les caches... Un petit fichier pourrait très bien être chargé entièrement en mémoire... Avec un gros fichier (plus gros que ton cache), tu devrais t'en rendre compte...  


---------------
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/
n°1196738
mart
Posté le 10-09-2005 à 19:48:44  profilanswer
 

Oki, merci beaucoup pour ton aide à nouveau très utile.


Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Programmation
  C

  [C] Provoquez des IO Error

 

Sujets relatifs
Probléme visual C++ library errorGestionaire parse error
Unknown Error au lancement de Visual Studio (2003 & 2005)error: invalid operands of types 'const char [15]' and 'short ..
link error - undefined reference to `std::ios_base::Init::Init()'linker error sur dev CPP avec la librairie tiff
Probleme On error gotoERROR C2533 constructor not allowed a return type!!
fatal error C1083error in your SQL syntax
Plus de sujets relatifs à : [C] Provoquez des IO Error


Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR