Atomic écrit — comment tempfile + os.replace prévenir la corruption JSON

Que se passe-t-il si la puissance coupe pendant qu'un processus écrit dans un fichier de configuration? Ou si le logiciel antivirus sous Windows verrouille brièvement un fichier mi-écriture? Si vous écrasez naïvement un fichier avec , quel que soit le contenu partiel existait au moment de l'interruption est ce qui reste sur le disque. Pour JSON, cela signifie généralement une syntaxe cassée — lance le prochain démarrage, et toute la configuration est effectivement perdue. Cet article passe par une technique standard pour empêcher cela : écrire d'abord dans un fichier temporaire, puis l'échanger en atomique. Note: "Atomique" signifie ici qu'une opération se termine entièrement ou ne se produit pas du tout — il n'y a pas de partialité, observable entre les états. C'est le même sens du terme utilisé pour les transactions dans la base de données. Pourquoi les écrasements directs sont dangereux tronquer efficacement le fichier d'abord, puis écrire le nouveau contenu. Si le processus est interrompu pendant cette fenêtre, le fichier reste vide ou contient un contenu incomplet. Les causes varient : une panne de courant, un logiciel antivirus qui bloque brièvement l'accès aux fichiers sous Windows, ou un outil de sauvegarde qui saisit le fichier à la mi-écriture. Cela se reproduit rarement pendant le développement local, mais dans un environnement de production à long terme, il se produira finalement avec une quasi certitude. La correction : écrire dans un fichier temporaire, puis l'échanger dans L'idée centrale est simple. Ne touchez jamais directement le fichier cible. Rédigez d'abord le nouveau contenu complet dans un fichier temporaire, confirmez que l'écriture a entièrement réussi et remplacez le fichier cible par ce fichier temporaire. génère un nom de fichier temporaire sans collision et retourne son descripteur de fichier. L'argument compte ici : placer le fichier temporaire dans le même répertoire que le fichier cible garantit que l'appel suivant reste dans un seul système de fichiers. Pourquoi est atomique Le noyau de ce modèle est l'appel final. La documentation officielle de Python indique que « sera une opération atomique sur Unix » et se comporte atomiquement sur Windows aussi, tant que les deux chemins sont sur le même système de fichiers. Sur les systèmes POSIX (Linux/macOS), cette carte correspond à l'appel système. Au niveau du noyau, l'échange d'une entrée de répertoire est une opération indivisible unique. Il n'y a pas d'état intermédiaire à observer — de l'extérieur, le fichier est soit dans son état pré-swap ou post-swap, jamais quelque chose entre. Sous Windows, Python 3.3+ implémente ceci de sorte que l'écrasement d'un fichier existant est géré atomiquement (à peu près équivalent à l'appel avec le drapeau). Grâce à cette propriété, si le processus meurt au milieu de , seul le fichier temporaire non nommé est affecté — le fichier de configuration réel reste intact dans n'importe quel état valide qu'il était avant. Forcer la persistance au disque avec Même avec un atomique, il ya un risque plus subtil: le contenu écrit par pourrait encore être assis dans le cache de page OS plutôt que physiquement sur le disque lorsque la puissance est perdue. Dans ce cas, le renommer lui-même pourrait être complété, mais le contenu du fichier renommé pourrait ne pas refléter ce qui a été écrit. s'adresse à ça. ne pousse que le tampon interne de Python vers le système d'exploitation — il peut toujours s'asseoir dans le cache de niveau OS. va plus loin et demande à l'OS d'attendre que les données soient effectivement écrites sur disque physique. La combinaison des deux étapes assure que le contenu du fichier temporaire est durablement sur le disque avant les temps d'exécution. Nettoyage après une écriture ratée Si l'écriture dans le fichier temp lui-même échoue partiellement (le disque complet, l'erreur de permission, etc.), n'est jamais atteinte, de sorte que le fichier cible n'est pas affecté. Mais le fichier temporaire à moitié écrit est laissé sur disque. Laissés sans surveillance, ils s'accumulent comme encombrants, donc il vaut la peine de les supprimer explicitement sur l'échec. Le imbriqué explique la possibilité qu'il échoue (déjà supprimé, aucune autorisation, etc.). Relever l'exception originale () permet à l'appelant d'apprendre que l'écriture a échoué. Garder contre les fichiers restants Depuis qu'il consomme le nom de fichier temporaire et l'échange dans le nom de la cible en cas de succès, les fichiers ne s'attardent normalement pas sous opération régulière. Mais dans un cas extrême — le processus obtient 'd dans la fenêtre étroite juste après le fichier temporaire est entièrement écrit, mais