Discussion :

[donquichotte]

Bonjour, petite question C++: je dois persister une donnée (string) dans un fichier assez frequemment dans mon programme, mais je voudrais remplacer à chaque fois l'ancienne donnée par la nouvelle, donc si possible, avoir un fichier d'une seule ligne, et ecraser à chaque fois l'ancien contenu par le nouveau.

Etant donné que le processus d'écriture doit se faire très souvent, il n'est pas vraiment question d'ouvrir et de fermer le fichier à chaque fois car c'est trop lent.

De plus, je ne peux pas écrire la donnée uniquement à la fin de mon programme, car il faut impérativement qu'en cas de crash, le fichier contienne la derniere donnée en date.

Grosso modo, pouvoir ouvrir mon fichier, ecrire ma donnée, revenir en début de fichier et réecrire par dessus.

Y a t'il des moyens de faire cela ? Merci beaucoup !!

[Alp]

Salut,

Tu peux te baser sur cette page pour faire des tests d'utilisation de seekp notamment, qui devrait t'aider.

[Sylvain Togni]

De plus, je ne peux pas écrire la donnée uniquement à la fin de mon programme, car il faut impérativement qu'en cas de crash, le fichier contienne la derniere donnée en date.

Il faudra au minimum faire un flush() pour écrire le contenu du buffer sur le disque. Et encore, je ne suis pas sur qu'en cas de crash le fichier soit valide s'il n'a pas été fermé, quelqu'un a un avis ?

[Alp]

Je crois qu'en cas de crash on a un état indéterminé pour le fichier... Comme le chat de Schrödinger

[Florian Goo]

On pourrait peut-être imaginer un système avec deux processus (processus, hein, pas threads) :

• le processus principal (ton programme tel qu'il est aujourd'hui, donc)
• un processus secondaire mémorisant la valeur de ta string

Le processus principal, au lieu d'écrire dans un fichier, envoie la valeur à mémoriser au processus secondaire.
Le processus secondaire surveille le processus principal à la façon d'un watchdog. Dés que le processus principal ne répond plus, pouf, on écrit dans le fichier et on ferme.
Sachant que ce second programme ne ferait que ça, il serait plus safe.

Bon, évidemment on a toujours le risque que l'ordinateur soit éteint à l'arrache ou que l'OS se plante…

Je crois qu'en cas de crash on a un état indéterminé pour le fichier... Comme le chat de Schrödinger

Toutes ces fois où j'ai fait de la physique quantique sans m'en rendre compte…

[3DArchi]

Le processus secondaire surveille le processus principal à la façon d'un watchdog. Dés que le processus principal ne répond plus, pouf, on écrit dans le fichier et on ferme.

Ou sauvegarder régulièrement en cas de changement (par expl ttes les secondes si le tps de sauvegarde<1s), ou dès que la valeur change en ayant un dbl buffer valeur en cours de sauvegarde/dernière valeur modifiée.

[Jean-Marc.Bourguet]

Il faudra au minimum faire un flush() pour écrire le contenu du buffer sur le disque. Et encore, je ne suis pas sur qu'en cas de crash le fichier soit valide s'il n'a pas été fermé, quelqu'un a un avis ?

flush va transmettre a l'OS. Il faut des connaissances sur l'OS pour faire plus (fsync sous Unix par exemple, mais il faut un file descriptor qu'il n'est pas encore possible d'optenir de maniere conforme).

[donquichotte]

Merci pour vos réponses ! Comme je vois que vous poussez la reflexion assez loin, je me dois de vous donner quelques précisions :

La sauvegarde de la donnée correspond à un message qui est reçu par mon programme, messages qui arrivent de façon totalement aléatoire (mais parfois avec des fréquences très élevées), et il faut vraiment que je fasse en sorte de sauvegarder le dernier reçu.

Donc une sauvegarde faite selon une période cyclique ne correspond pas à ce que je recherche.


Je fais pour les moments quelques tests et me contentant d'un fseek, sans flush et en ne fermant le fichier qu'en cas d'arrêt normal, et je reflechi à la façon d'implémentation la solution de Florian.

Merci encore pour vos réponses !

[Jean-Marc.Bourguet]

Je fais pour les moments quelques tests et me contentant d'un fseek, sans flush et en ne fermant le fichier qu'en cas d'arrêt normal,

Sans flush, il y a toute les chances qu'au moins une partie de ton message ne soit jamais transmit a l'OS -- sans parler d'arriver sur le disque.

Un flush devrait le rendre plus robuste a un arret intempestif du programme, sans le rendre robuste a un crash de la machine.

Un flush + qqch de specifique a l'OS du genre fsync le rendrait plus robuste aussi dans le cas d'un arret intempestif de la machine.

[wiztricks]

open permet d'ouvrir les fichiers avec le flag O_SYNC qui force les écritures disque synchrones.
De même, pread et pwrite permettent de lire/écrire nbytes à partir de l'offset donné en paramètre.

Pour revenir avec la question posée, ce n'est pas parce qu'on demande via flush ou fsynch (ou pwrite) à l'OS une écriture disque synchrone que les données seront récupérables en cas de crash.

Il faudrait pour ce faire que l'opération soit "atomique" ce qui n'est pas garanti: en fonction de la taille de l'IO et de l'allocation des blocks disques, cela pourra induire plusieurs opérations d'écriture et donc, une inconsistance "potentielle".

La corruption est relativement simple à détecter puisqu'on peut associer un checksum ou un check byte aux données écrites. Pour ce qui est de la récupération, ie utiliser le dernier message "bien écrit", cela peut être simple dans le cas ou la taille des messages est bornée ou tortueux si elle doit être "variable".
-W