Éteignez lors de l'exportation à mi-chemin. Ne donnez pas la moitié du fichier à l’utilisateur : terminez d’abord l’écriture puis publiez.

Écrit pour les développeurs qui effectuent des exportations, des téléchargements ou des traductions de fichiers. Si le service est redémarré alors que le fichier est à moitié écrit et que le lien de téléchargement est déjà ouvert à l'utilisateur, celui-ci peut obtenir un produit semi-fini qui ne peut pas être ouvert. Ce type de problème n'est pas seulement « le fichier ne peut pas être ouvert de temps en temps », la cause première est que le système traite les produits inachevés comme des résultats officiels.

Après avoir lu cet article, vous pouvez clairement définir les limites de la publication : terminez d'abord la rédaction et la vérification, puis laissez l'entrée officielle prendre effet. Cet article expliquera également ce qu'il faut faire selon différentes méthodes de stockage et ce qui doit encore être vérifié après la publication.

Cet article utilise des échantillons synthétiques pour démontrer la méthode de traitement. Le code a été vérifié avec des exemples dans un environnement isolé ; cela ne représente pas une garantie de tous les fichiers réels ou des performances du produit. Avant de traiter des documents importants, veuillez conserver les originaux et les examiner en fonction des limites et des éléments d'acceptation du texte.

Si l'alimentation tombe en panne au milieu de l'exportation, comment puis-je éviter de transmettre la moitié du fichier ? Conclusion en une phrase

L'approche principale est la suivante : Écrivez d'abord le fichier temporaire, puis remplacez le chemin officiel ou mettez à jour le pointeur officiel une fois toutes les vérifications réussies.

Pourquoi avez-vous remis la moitié du dossier ?

Le service redémarre lorsque le fichier est écrit à mi-chemin et si le lien de téléchargement est déjà disponible, l'utilisateur obtiendra le produit inachevé. Cela suggère que le problème vient du moment de la publication, et pas seulement de l’opération d’écriture elle-même.

L'ajout d'une couche de capture d'exceptions à l'opération d'écriture ne peut gérer que les erreurs pouvant être détectées par le programme pendant le processus d'écriture. Ce qu’il faut vraiment surveiller, c’est : quels États sont autorisés à être visibles du monde extérieur.

Écrivez d'abord le fichier temporaire, puis remplacez l'entrée officielle

Dans le système de fichiers local, la méthode courante consiste à écrire un fichier temporaire dans le répertoire cible, puis à appeler os.replace après l'avoir écrit et fermé. Le même répertoire peut éviter les problèmes courants de remplacement entre systèmes de fichiers.

Il convient de noter que le remplacement atomique décrit uniquement le nom que le lecteur voit et ne signifie pas que les données seront conservées après une panne de courant.

Références : Python tempfile.

Utiliser le plan de statut pour spécifier la séquence de publication

Le code ci-dessous ne crée ni n'écrase réellement le fichier, mais vérifie plutôt le plan de livraison : seules l'écriture, la fermeture et la vérification du contenu sont terminées avant que le chemin officiel puisse être remplacé.

def publish_plan(written, closed, content_ok, same_filesystem):
    if not written:
        return ("write_temporary",)
    if not closed:
        return ("close_temporary",)
    if not content_ok:
        return ("quarantine_temporary",)
    if not same_filesystem:
        return ("prepare_destination_temporary",)
    return ("replace_destination", "confirm_readable", "mark_ready")

assert publish_plan(False, False, False, True) == ("write_temporary",)
assert publish_plan(True, False, True, True) == ("close_temporary",)
assert publish_plan(True, True, False, True) == ("quarantine_temporary",)
assert "mark_ready" not in publish_plan(True, True, True, False)
assert publish_plan(True, True, True, True)[-1] == "mark_ready"

Il s'agit d'un test de protocole, pas d'une expérience de panne de courant. Un véritable rédacteur de fichiers devra également gérer le nettoyage des exceptions, les autorisations et les différences de plate-forme. N'emballez pas un succès de lecture et d'écriture ordinaire, car "la sécurité en cas de mise hors tension a été prouvée".

Quels états autorisent le téléchargement

Ne soyez pas rigide sur le changement de nom du stockage d'objets

Les magasins d'objets n'ont généralement pas exactement la même sémantique de renommage de répertoire que les systèmes de fichiers locaux. Une approche plus appropriée est la suivante :

1. Téléchargez des produits à l'aide de clés d'objet immuables.
2. Vérifiez le contenu après le téléchargement.
3. Après avoir réussi la vérification, mettez à jour le pointeur officiel dans la base de données.

Si un CDN est également impliqué, les clés de cache et la conservation des anciennes versions doivent également être prises en compte ensemble.

La fin de la traduction doit inclure la livraison du fichier

Lors de la connexion de l'état de traitement de OmniDoc (portail produit) à votre propre produit, le succès du téléchargement local ne peut pas être affiché immédiatement après la réception de « Fin du traitement ». Vous devez d'abord confirmer que le manuscrit de traduction enregistré peut être lu et est du type correct avant de définir la tâche comme livrable.

L'achèvement perçu par l'utilisateur est enfin d'obtenir un fichier pouvant être ouvert.

📊 Comparaison de base

🎯 Quelle méthode vous convient ?

Si votre produit est enregistré sur le disque local

Écrivez un fichier temporaire dans le répertoire cible, puis remplacez le chemin officiel par os.replace une fois la vérification réussie.

Si votre produit est stocké dans un stockage d'objets

Utilisez une clé d'objet immuable pour télécharger, puis mettez à jour le pointeur officiel après avoir réussi la vérification.

Si vous avez des exigences plus élevées en matière de sécurité des données après une panne de courant

Ne comptez pas uniquement sur le remplacement atomique, mais étudiez également la sémantique de synchronisation des fichiers et des répertoires et vérifiez-la par injection de fautes.

Si votre aval est un téléchargement utilisateur

Le lien de téléchargement n'est fourni que lorsque l'état du produit est « Lisible et correspondances de vérification ».

❓ Questions fréquemment posées (FAQ)

1. Le remplacement atomique peut-il garantir que les données ne seront pas perdues après une panne de courant ?

ne peut pas. Le remplacement atomique décrit le nom que le lecteur voit, ce qui ne signifie pas que les données seront conservées après une panne de courant.

2. Pourquoi les fichiers temporaires sont-ils créés dans le répertoire cible ?

Le même répertoire peut éviter les problèmes courants de remplacement entre systèmes de fichiers.

3. Le stockage d'objets peut-il utiliser directement le renommage pour publier des fichiers ?

Une utilisation intensive n'est pas recommandée. Le stockage d'objets n'a généralement pas exactement la même sémantique de renommage de répertoire que les systèmes de fichiers locaux et est plus adapté aux clés d'objet immuables ainsi qu'aux pointeurs formels.

4. Que faire des produits dont la vérification échoue ?

Il doit être isolé, non publié, et les informations de débogage doivent être conservées.

📝Résumé

Les limites de publication déterminent ce que les utilisateurs peuvent voir. Terminez d'abord la rédaction et la vérification, puis laissez l'entrée officielle prendre effet, afin d'éviter de remettre des produits inachevés aux utilisateurs.

Essayez-le maintenant : téléchargez le document pour lancer la traduction, en conservant la mise en page d'origine.