Windows Win32 C++ question sur le vidage de l'activité des fichiers sur le disque.
J'ai une application externe (exécutée à l'aide de CreateProcess) qui crée des fichiers, c'est-à-dire que lorsqu'elle revient, elle a créé un fichier avec un certain contenu.
Comment puis-je m'assurer que le fichier créé par le processus a bien été effacé sur le disque, avant de poursuivre ?
J'entends par là non pas les tampons C++ mais le vidage du disque (par exemple, FlushFileBuffers).
Rappelez-vous que je n'ai pas accès à un HANDLE de fichier - tout ceci est bien sûr caché dans le processus externe.
Je suppose que je pourrais ouvrir mon propre handle sur le fichier et ensuite utiliser FlushFileBuffers, mais ce n'est pas sûr que cela fonctionne (puisque mon handle ne contient rien qui nécessite un flushing).
Enfin, je veux que cette opération s'exécute dans un espace utilisateur non administrateur, de sorte que je ne puisse pas utiliser FlushFileBuffers sur un volume entier.
Des idées ?
UPDATE : Pourquoi est-ce que je pense que c'est un problème ?
Je travaille sur une application de sauvegarde de données. Essentiellement, elle doit créer des fichiers comme décrit. Elle doit ensuite mettre à jour sa base de données interne (en utilisant une base de données intégrée à SQLite).
J'ai récemment eu un problème de corruption de données qui s'est produit pendant un écran bleu (dont la cause n'était pas liée à mon application).
Ce qui m'inquiète, c'est l'intégrité de l'application en cas de panne du système. Et oui, je m'en préoccupe car cette application est une application de sauvegarde de données.
Le cas d'utilisation qui me préoccupe est le suivant :
- Un petit fichier de données est créé à l'aide d'un processus externe. Cette écriture est en attente dans le cache du système d'exploitation pour être écrite sur le disque.
- Je mets à jour la base de données et je fais un commit. C'est une activité du disque. Cette écriture est également en attente dans le cache du système d'exploitation.
- Une défaillance du système se produit.
Comme je le vois, nous sommes maintenant dans une condition de course potentielle. Si "1" est purgé et que "2" ne l'est pas, tout va bien (puisque la transaction DB n'a pas été validée). Si aucun des deux n'est purgé ou si les deux sont purgés, tout va bien également.
Si je comprends bien, les écritures ne seront pas déterministes, c'est-à-dire que je ne sais pas si le système d'exploitation garantira l'écriture de "1" avant "2". (Est-ce que je me trompe ?)
Donc, si le "2" est évacué, mais pas le "1", nous avons un problème.
J'ai observé que la base de données était correctement mise à jour, mais que le fichier contenait des déchets : les deux derniers tiers des données étaient des "zéros" binaires. Je ne sais pas à quoi cela ressemble lorsqu'une partie du fichier est vidée au moment du bluescreen, mais je ne serais pas surpris que cela ressemble à cela.
Puis-je garantir que c'est la cause ? Non, je ne peux pas le garantir. Je ne fais que spéculer. Il se peut que le fichier ait été "naturellement" corrompu en raison d'une défaillance du disque ou à la suite de l'écran bleu.
En ce qui concerne les performances, c'est quelque chose que je pense pouvoir gérer.
Par exemple, le comportement par défaut de SQLite est d'effectuer un vidage complet du fichier (en utilisant FlushFileBuffers) chaque fois que vous validez une transaction. Ils sont très clairs sur le fait que si vous ne le faites pas, au moment de la panne du système, vous pourriez avoir une base de données corrompue.
De plus, je pense que je peux atténuer le problème de performance en ne vidant les données qu'aux "points de contrôle". Par exemple, écrire 50 fichiers, vider le lot et ensuite écrire dans la base de données.
Quelle est la probabilité que tout cela pose un problème ? Je n'en sais rien. Mais mon application pourrait bien être en train d'archiver au moment de la défaillance du système ou aux alentours, donc c'est peut-être plus probable que vous ne le pensez.
J'espère que ça explique pourquoi je veux faire ça.
