J'ai mis en place une interface d'écriture personnalisée pour mon programme cloud. Mon problème jusqu'ici est qu'après que j'ai fini de copier des fichiers sur mon graveur et que j'ai fermé l'enregistreur, l'auteur a encore quelques écritures à faire (en général 4 écritures d'environ 4096 octets chacune). La dernière écriture est généralement inférieure à 4096.Le programme Golang ferme le fichier avant que l'écriture ne soit terminée
Cela ne s'est pas encore produit, mais je sais que c'est une probabilité de 1/4096 que la dernière écriture soit de 4096 octets et que mon programme ne se termine pas. J'utilise ceci pour un programme de compression et io.EOF n'est pas efficace car chaque bloc d'écriture en a un, et vérifier si l'auteur est fermé arrive trop tôt alors qu'il y a encore des écritures à faire.
Quelle est la meilleure façon de gérer cette situation?
*** EDIT ***** J'ai fini par implémenter une méthode plus robuste Write(), Flush() et Close(). Maintenant, tout est bon si j'utilise différer Close() mais je reçois toujours le même problème si j'appeler manuellement Close() à la fin
Je ne comprends pas, comment ne savez-vous pas si vous avez déjà écrit les données? Si vous avez EOF sur chaque morceau, vous faites quelque chose de mal. – JimB
Donc, j'ouvre un fichier, copiez des octets et fermez-le. Cette partie fonctionne. Le sous-jacent "Writer" prend généralement du temps pour rattraper - je suppose de l'écriture des morceaux. Donc, je reçois une situation où le fichier est fermé, mais l'écrivain sous-jacent est presque fini de rattraper son retard. – Godfrey
Un rédacteur normal bloquerait sur Fermer jusqu'à ce qu'il termine toutes les écritures tamponnées. Je ne sais pas ce qu'est votre Writer sous-jacent, mais cela ne semble pas fonctionner correctement. – JimB