Comment annuler l'écriture d'un fichier sur un disque

Bonjour,

J'ai un traitement (.vbs) qui s'exécute toutes les minutes.
J'écris dans plusieurs fichiers (log, trace, ...).
Sauf que, à la fin du traitement, sur le résultat d'un test, je dois décider si je garde, ou non, ces fichiers.

Naïvement, je pensais que si je ne faisais pas un NomFic.Close, le fichier n'étant pas fermé, il "n'existerait pas" sur le disque.
Et bien non : À priori, le fait d'écrire dans un fichier (write) le matérialise définitivement sur le disque. Le .Close ne servirait donc, à priori, qu'à le rendre disponible (unlock) pour d'autres traitements.

D'un autre côté, je suis content de ce mécanisme "automatique" de sauvegarde du fichier car, en cas de plantage (si, si, ça m'arrive) je suis bien content d'avoir un fichier trace qui s'arrête au moment où "boum!".
Ce qui m'ennuie, c'est que je n'ai pas la possibilité "d'annuler volontairement" l'existence du fichier sur le disque (une sorte de CancelEvènement).

Je vais donc supprimer (del) les fichiers écris puisque je ne peux pas annuler leur existence par l'absence d'un .Close.

La question que je pose à la communauté est celle-ci :
Êtes-vous d'accord avec mon analyse ?

Merci pour vos avis.
Cordialement.
Gilles Cartairade

En quelque sorte oui, mais parfois la méthode Close sert à finaliser l'enregistrement du fichier sinon, le fichier serait tronqué.

En réponse au titre du message : Ne créer et n'écrire dans le fichier que si on est sûr de le vouloir exister sur le disque.

J'ai continué à chercher dans mon coin.

D'abord, sur le site de Microsoft, il est mentionné que la fin du script (propre ou non) fermait automatique tous les fichiers (texte) ouverts.
Et j'ai découvert que l'écriture physique se faisait à l'OPEN : Si on ouvre un fichier et on le ferme (.close, .quit) de suite, le fichier est bien créé avec zéro en taille.
On aurait pu penser que l'écriture se fasse dans un "tampon" et que le "commit" se fasse au .Close. Mais non.

Ensuite, l'écrire que si l'on est sûr de le voir exister ...
1) Tout est dans le problème du volume généré : Dans mon cas, je génère 3 fichiers qui représentent ~2 Mo cumulé toutes les minutes/24 heures/365 jours ...
2) Dans mon cas, 99% du temps, le traitement ne doit rien écrire car il n'y a pas d'information significative à garder, par contre, quand il y en a (détecté en milieu de traitement), toutes les informations déjà écrites deviennent importantes.
3) Dans le cas d'un programme de vérification, par exemple, il peut être intéressant de stocker tous les résultats des différents steps pour les analyser en cas de problème, mais s'il n'y a aucun problème, les garder ne sert à rien.

Stocker les informations dans une table, en mémoire, puis l'écrire sur disque si nécessaire, n'est pas valable en cas de plantage du programme : Vous perdez toutes les infos.

L'éternel problème du verre à moitié plein/moitié vide !
Cordialement.

bonjour,

Citation:

---

On aurait pu penser que l'écriture se fasse dans un "tampon" et que le "commit" se fasse au .Close. Mais non.

---

et c'est heureux car cela évite - de façon simple et robuste - de se retrouver en conflit avec un autre process qui aurait eu
dans l'intervalle la bonne idée de créer dans le même répertoire un fichier du même nom... :roll:

j'observe que les contraintes que tu énonces ne sont pas cohérentes
tu ne peux pas à la fois souhaiter un différé d'écriture sur le disque et écarter la solution d'un stockage temporaire en mémoire
pour te protéger d'un plantage...
la solution consiste simplement après un certain volume de données - ou tout autre critère - à fermer le fichier et le détruire
avec la méthode delete comme ceci :

Code:

---

1 2 3 4 5 6 7 8

Dim fso, txtFile, objFile Set fso = CreateObject("Scripting.FileSystemObject") Set txtFile = fso.CreateTextFile("c:\testfile.txt", True) txtFile.WriteLine("Ceci est un test.") 'TEST QUELCONQUE txtFile.Close Set objFile = fso.GetFile("c:\testfile.txt") objFile.Delete

---

Bonjour,

Je suis entièrement d'accord avec toi.
D'ailleurs, je supprime ( obj.DeleteFile(string avec expressions régulières) ) les fichiers en fin de traitement quand nécessaire.

À dire vrai, j'ai eu une réflexion en "escalier" : J'ai écris tout le traitement - qui fonctionne parfaitement - puis, le "métier" m'a demandé une modification fonctionnelle.
Ce qui m'a amené à modifier (légèrement) le programme (qui faisait déjà 3000 lignes).
L'effet de bord a été une inflation de fichiers inutiles.
J'ai donc rajouté un IF afin d'éviter le .Close ... qui n'a pas donné l'effet escompté, j'ai donc cherché à savoir pourquoi ce stupide ordinateur ne fonctionnait pas comme je voulais ...
L'effet Tunnel dans toute sa beauté !

Dans l'absolu, j'aurais dû revoir fortement le programme, voire le découper ... mais, quand un (gros) programme tourne bien, on a un peu la flemme de tout revoir pour un "petit truc" ... qui peut bien prendre la tête, d'ailleurs, et généralement pour 3 fois rien, de plus.

Cordialement.