OK, afin d'expliquer; Je développe un système pouvant subir une panne de courant à un moment donné, un point que je suis testé est directement après avoir écrit un fichier à l'aide d'un streamwriter. Le code ci-dessous: écrit le contenu de Toutes les idées seraient les bienvenues! shellconfigwriter (liste de chaînes) sur un fichier utilisé comme magasin temporaire, Ensuite, il est copié sur l'original. Maintenant, une fois que ce code a fini d'exécuter la puissance est perdue, lors de la remise en marche, le fichier game.cfg existe et est la bonne taille, mais est complètement vide. Au début, je pensais que cela était dû à la mise en cache d'écriture étant activé sur le disque dur, mais même avec elle, il se produit toujours (même moins souvent). .close () instructions et appelez .flush () après chaque opération d'écriture des fichiers encore finir par un blanc. Je pourrais d'abord aller une étape et créer une sauvegarde du fichier d'origine avant de créer le nouveau, puis j'ai assez de sauvegarde pour faire une vérification d'intégrité, mais je ne pense pas que cela aidera à résoudre le problème sous-jacent ( que lorsque je lui dis d'écrire, de flush et de fermer un fichier ... ce n'est pas!).
3 Réponses :
Tout d'abord, vous n'avez pas à appeler Pour protéger contre ces scénarios, une procédure commune consiste à utiliser des fichiers d'indicateur d'état / condition. Vous utilisez l'existence ou la non-existence sur le système de fichiers d'un fichier zéro octet avec un nom particulier pour indiquer à votre programme où se rapportera à nouveau lors de la reprise. Ensuite, vous ne créez ni ne détruisez les fichiers qui déclenchent un état particulier jusqu'à ce que vous soyez sûr vous avez atteint cet état et complété le précédent.
L'inconvénient est que cela pourrait vouloir dire jeter beaucoup de travail de temps en temps. Mais la prestation est que cela signifie que la partie fonctionnelle de votre code ressemble à la normale: il y a très peu de travail supplémentaire à faire pour rendre le système suffisamment robuste. shellconfigwriter.close () là. L'instruction en utilisant prendra en charge. Ce que vous voudrez peut-être faire à la place pour se protéger contre l'échec de l'alimentation est appeler shellconfigwriter.flush () .
Quelque chose d'autre que vous voudrez peut-être envisager, c'est que si une panne de courant peut vraiment se produire à tout temps , cela pourrait arriver au milieu d'une écriture, de telle sorte que seuls certains des octets le rendent dans un fichier. Il n'y a vraiment aucun moyen d'arrêter ça.
D'accord, je n'avais pas la méthode .Close () à l'origine pour cette raison exacte, mais je manquais de choses à essayer! Je vais essayer de rincer après chaque appel d'écriture, voir ce qui se passe alors.
Pas de chance, je n'ai toujours pas écrit une seule ligne.
Vous voulez définir autoflush = true;
Yeh je pourrais, mais dans le but de cet exemple de code, il est 1 ligne de chaque sens; Rincer chaque pour l'itération ou ensemble autoflush à true. Il produit toujours le même résultat, c'est-à-dire qu'il produit toujours un fichier vierge.
Êtes-vous sûr de ne pas simplement écrire des lignes vierges dans le fichier? ; p
Gardez le système d'exploitation de tamponner la sortie à l'aide du paramètre fichierOptions du constructeur d'objet FileStream
Une alternative à "nouveau filtream" est la méthode Static Fichier.create: "File.create (@" D: \ XXX \ shell \ config \ game.cfg.bak ", 0x1000, FileOptionS.writethrough, null)". Il a quelques paramètres de moins et pourrait avoir l'air plus propre dans le code.
Cela fonctionne bien lorsque je teste pour écrire un fichier texte puis débranchez immédiatement. Le fichier est enregistré avec succès.
Est
game.cfg.bak vide aussi?C # a un tampon, le système d'exploitation a un tampon ou deux et votre disque physique a un tampon. Je pense que vous ne pouvez influencer que les deux premiers du C #. Vous perdrez toujours des données dans une situation de perte de puissance, la question est de savoir combien.