Le CSV est bien envoyé sur le serveur SFTP, mais le traitement destinataire continue d’importer l’export de la veille. Le journal confirme une taille, puis affiche une erreur au renommage. Le risque est de croire qu’un dépôt confirmé a déjà remplacé le fichier attendu : l’envoi temporaire et la publication sous le nom lu par le partenaire sont deux opérations différentes. Refaire tout le transfert peut masquer le refus sans expliquer quel document reste disponible.
Le scénario fictif EXP-517 suit un export de 39 octets, une révision r2 et un chemin temporaire attribué à une tentative A7. Le nom final reste imposé par le consommateur. L’ancien dossier EXP-516 ne doit pas disparaître de l’historique lorsque la publication du nouveau fichier échoue. Cette contrainte rend le diagnostic utile aux échanges ERP, aux reprises de fichiers partenaires et aux traitements nocturnes dont le nom reste fixe.
Un programme original exécute 76 contrôles avec Paramiko 5.0.0. Le véritable client produit treize requêtes applicatives sur des canaux en mémoire ; six échanges INIT/VERSION préparés portent le total à dix-neuf paquets. Il n’ouvre aucune connexion TCP ni session SSH réelle. Ce témoin permet de lire les opérations et les exceptions de cette bibliothèque, sans certifier les permissions, le contenu ou l’atomicité d’un serveur SFTP.
Une prestation de middleware sur mesure pour vos échanges SFTP peut commencer par ce refus de publication précis. Notre accompagnement en intégration API et fichiers entre logiciels métier rapproche le producteur, le transport et le lecteur de l’export. Vous allez comprendre comment distinguer les deux types de renommage, interpréter leurs refus et préparer une reprise qui conserve la bonne révision.
Pour qui : un export reçu sous un nom que le destinataire ne lit pas
Retrouver le nom réellement surveillé par le consommateur
Le cas concerne une chaîne dans laquelle un composant produit le CSV, le dépose sous un nom temporaire, puis le rend visible au traitement suivant. Un ERP peut produire ce fichier directement ou passer par un adaptateur ; il faut vérifier cette interface avec son intégrateur. Le transport SFTP ne décrit ni le format métier du CSV ni la règle d’import. Le premier entretien retrouve donc le producteur exact, les deux chemins et le composant chargé de changer le nom.
Le destinataire peut surveiller un nom fixe, filtrer une extension ou parcourir régulièrement un répertoire. Ce polling n’a pas les mêmes conséquences qu’une lecture déclenchée par une notification applicative. Dans EXP-517, le fichier temporaire ne correspond pas au nom final attendu. Une barre de progression à cent pour cent signifie seulement que le composant de transfert a terminé son travail déclaré. Elle ne dit pas quelle révision sera choisie au prochain passage du lecteur.
Séparer le refus de publication du refus d’import
Une erreur de connexion SSH, un dépôt refusé et un renommage rejeté demandent des investigations différentes. Un fichier déjà publié mais rejeté pour une colonne absente ouvre encore un autre dossier. Le diagnostic proposé vise la frontière entre dépôt temporaire et nom final. Il ne remplace pas une analyse de format, un contrôle antivirus ou une réparation des règles de gestion. Le journal doit montrer à quelle opération la chaîne s’arrête, avec la référence d’extraction qui était attendue.
Le coût caché apparaît quand l’exploitation relance le job jusqu’à ce qu’un fichier semble enfin accepté. Plusieurs fichiers temporaires s’accumulent, la source a parfois changé et la personne qui reçoit le CSV ne sait plus quel exemplaire prendre. Un changement volontaire de révision reste possible, mais il doit être explicite. La synchronisation avec l’ERP ne doit pas remplacer EXP-517 par une extraction ultérieure simplement parce que cette dernière passe plus facilement le transport.
Ce que confirme réellement le dépôt du fichier temporaire
Lire la confirmation de taille dans le client installé
La documentation de SFTPClient.putfo décrit le contrôle effectué avec confirm=True : le client examine la taille retournée par stat après le transfert. Dans notre exécution, il prépare OPEN, WRITE, CLOSE puis STAT pour le fichier temporaire. La taille fournie au parseur est de 39 octets, comme celle de la source. Le client retourne les attributs reçus ; aucun import ERP n’est interrogé.
Ce rapprochement reste limité. Les attributs de taille ne sont ni une lecture du contenu ni une empreinte distante de celui-ci. Notre programme observe aussi les octets placés dans le payload WRITE et les compare à sa source locale, mais aucun disque distant ne les conserve. Le mapping entre EXP-517, la révision r2 et la tentative A7 vient de notre reçu applicatif. Il ne peut pas être reconstitué à partir d’une taille et d’un nom de fichier seulement.
Qualifier aussi le chemin temporaire avant d’y écrire
Le code épinglé du client ouvre le fichier de putfo en mode wb. Le relevé contient les indicateurs natifs d’écriture, de création et de troncature, soit la valeur 26 dans cette version. Cette opération n’est donc pas une création exclusive à supposer sans vérification. Un chemin temporaire partagé entre producteurs peut devenir un autre point de collision, avant même la demande de renommage du nom final.
La proposition attribue un chemin temporaire à une tentative connue et conserve les octets source qui lui correspondent. Ce choix local n’établit aucun verrou serveur : les droits, l’attribution du répertoire et les producteurs concurrents restent à tester. Le deuxième transfert du laboratoire reçoit une taille de 38 au lieu de 39 et déclenche l’erreur native de confirmation. Ce cas concret est arrêté avant tout renommage ; il ne démontre pas le contrôle d’une somme de vérification distante.
rename et posix_rename ne demandent pas la même opération
Reconnaître le renommage standard et son retour générique
Le contrat documenté par Paramiko distingue rename, qui utilise le renommage SFTP standard et attend une destination absente, de l’extension de renommage POSIX. Le témoin standard produit l’opération 18, SSH_FXP_RENAME, avec les deux chemins. Notre réponse préparée fournit ensuite le statut 4 et le message « Failure ». Le relevé ci-dessous associe les champs décodés de la requête à ce retour fourni ; prepared_status ne fait pas partie de la requête envoyée.
{
"opcode": 18,
"request_id": 5,
"oldpath": "/outbound/EXP-517-r2-A7.csv.part",
"newpath": "/outbound/inventory.csv",
"prepared_status": 4
}L’exception obtenue est une OSError dont errno vaut None. Elle ne prouve pas, à elle seule, qu’un fichier final existe déjà. Le scénario de nom fixe rend cette hypothèse pertinente, mais d’autres causes doivent être qualifiées avec le serveur et les chemins concernés. Transformer toute erreur générique en « destination déjà présente » conduirait à choisir un remplacement sans avoir établi pourquoi la demande initiale a été refusée.
Vérifier l’extension au lieu d’en déduire la disponibilité
La méthode posix_rename produit une requête étendue, opération 200, qui nomme posix-rename@openssh.com. Le contrat OpenSSH épinglé décrit une sémantique POSIX de renommage et son annonce de version 1. Cette possibilité de remplacement doit correspondre à l’intention autorisée sur le nom final. Elle ne constitue pas un réglage à activer indistinctement sur tous les fichiers ou tous les serveurs SFTP.
Notre canal sans annonce d’extension reçoit tout de même la requête étendue du client, puis fournit le statut 8 préparé. Le chemin exécuté de Paramiko 5.0.0 n’a donc pas bloqué cet appel en analysant préalablement l’annonce. L’exception résultante reste générique dans notre observation. La version 5.0.0 désigne la bibliothèque Python ; les six échanges de version du laboratoire utilisent SFTP 3. Ce sont trois informations différentes à conserver : client installé, protocole utilisé et extensions du service effectivement retenu.
Exercice : suivre les requêtes et les refus du client Paramiko
Exécuter le client sur un canal de paquets préparés
Le programme complet de publication SFTP emploie Paramiko 5.0.0 sous Python 3.14.8. Le canal en mémoire fournit des paquets préparés et fragmente leur lecture. Le client conserve son encodeur, son lecteur de paquets et sa conversion native des statuts. Le laboratoire n’implémente pas le stockage d’un serveur : une réponse de succès fournie au parseur n’entraîne aucune écriture distante et ne représente aucune validation de clé hôte.
python3 -m venv .venv-sftp
.venv-sftp/bin/python -m pip install paramiko==5.0.0 cryptography==50.0.2 bcrypt==5.0.0 pynacl==1.6.2
.venv-sftp/bin/python -B sftp_rename_publication.py
# checks_passed: 76
# prepared_application_requests: 13
# prepared_init_version_exchanges: 6
# prepared_sftp_packets: 19
# real_tcp_connections: 0
# real_ssh_handshakes: 0
# real_http_calls: 0La préparation de l’environnement demande un accès au registre de paquets ; elle est distincte de l’essai fermé. Les versions indiquées correspondent à celles relevées lors de l’exécution. Les gardes refusent les connexions réelles et toute tentative d’ouverture SSH. Les dix-neuf paquets observés comprennent treize requêtes applicatives et six négociations INIT/VERSION de SFTP, pas six authentifications SSH. Cette distinction évite de faire passer l’échange de version d’un protocole en mémoire pour une recette de connexion au service du partenaire.
Examiner les refus avant le seul retour de succès
Le premier canal reçoit quatre opérations de transfert puis un renommage standard refusé. Quatre autres canaux observent une extension refusée sans annonce préalable, un refus de permission, un statut de chemin introuvable et un succès d’extension préparé. Le dernier canal examine le transfert dont la taille confirmée diffère. Cela représente treize opérations au total. Chaque réponse appartient à son propre cas ; le succès n’est pas une preuve qu’un serveur aurait finalement accepté une relance après les refus précédents.
| Situation préparée | Résultat observé |
|---|---|
| Renommage standard refusé | Opération 18, OSError sans errno |
| Extension absente de l’annonce | Requête étendue tout de même émise |
| Permission refusée | PermissionError, errno 13 |
| Chemin introuvable | FileNotFoundError, errno 2 |
| Taille confirmée différente | Erreur avant tout renommage |
| Succès de renommage préparé | Aucune nouvelle référence ERP |
Le programme refuse aussi une source modifiée à taille égale, une autre révision et chacun des deux chemins altérés, avant une nouvelle requête. Le reçu et ces décisions restent en mémoire. L’état ERP fictif conserve EXP-516 et laisse la nouvelle référence vide, y compris après le succès technique préparé. Le seuil d’admission testé porte sur la correspondance locale de la source et du contexte ; il ne transforme pas le client SFTP en arbitre de l’acceptation du document par la gestion.
Erreurs fréquentes : relancer un nom sans retrouver la tentative
Distinguer le code reçu de la cause qui reste à établir
Le statut 3 préparé devient une PermissionError avec errno=13. Le statut 2 devient une FileNotFoundError avec errno=2. Ces observations indiquent comment le client épinglé traduit les réponses, sans identifier le droit précis ou le chemin fautif sur un service réel. Un chemin introuvable peut concerner plusieurs éléments de l’opération. Le support relève donc les deux noms, la racine du compte SFTP et la configuration attendue, avant de conclure que le fichier source aurait disparu.
Le code 8 fourni dans le cas d’extension n’apparaît pas comme un numéro errno dans l’exception obtenue. Le relevé du laboratoire le connaît parce qu’il a préparé la réponse ; une application qui reçoit seulement l’exception ne doit pas lui inventer ce champ. La journalisation conserve l’opération et le contexte autorisé, puis rapproche le diagnostic de la configuration serveur. Les messages et les chemins peuvent contenir des informations sensibles : on collecte ce qui aide à attribuer le refus, sans recopier des secrets de connexion.
Ne pas remplacer une incertitude par une suppression préalable
Un timeout après la demande de renommage laisse une question supplémentaire : le serveur a-t-il exécuté l’opération avant la perte du retour ? Un retry qui ne retrouve plus le temporaire ne répond pas à cette question. L’équipe doit identifier la tentative et examiner le résultat avec la méthode de contrôle convenue. La présence d’un fichier final de même taille ne suffit pas si une ancienne révision pouvait déjà occuper ce nom. L’idempotence du traitement applicatif doit préciser ce qui est repris et quelles preuves empêchent une deuxième publication incohérente.
Supprimer d’abord le nom final pour rendre le renommage standard possible crée une autre séquence, avec un intervalle où l’ancien fichier peut manquer. Notre trace ne contient aucune opération REMOVE et aucun repli automatique de ce type. Le protocole OpenSSH décrit par ailleurs fsync@openssh.com comme une extension distincte sur un handle ouvert ; elle n’apparaît pas dans nos paquets. Ni le succès préparé de renommage, ni son nom POSIX ne démontrent ici une conservation durable après panne. Le serveur, son stockage et les lecteurs concurrents appartiennent à la recette connectée.
Plan d’action : reprendre EXP-517 jusqu’au fichier effectivement consommé
Attribuer la décision de remplacement au bon responsable
Le pilote retient une extraction et un destinataire, avec leurs références exactes. Le producteur précise comment retrouver les octets de la révision r2 ; l’exploitant du serveur qualifie le compte, les chemins et les opérations disponibles. Le responsable du traitement destinataire explique ce qu’il lit et ce qui autorise un import. Lorsque l’ERP est maintenu par un autre intégrateur, Dawap coordonne ces vérifications avec lui. Une connexion de fichiers ne doit pas devenir une modification implicite des règles d’extraction ou de gestion du logiciel.
- Retrouver la source, sa révision et les chemins de la tentative interrompue.
- Identifier la méthode et le retour exacts du renommage, avec le client installé.
- Qualifier le remplacement autorisé et les capacités du serveur destinataire.
- Provoquer refus, changement de source et perte de réponse sur le périmètre de recette.
- Rapprocher le fichier final et sa prise en charge avant de diffuser une nouvelle référence.
Dans le middleware à construire, l’instrumentation relie EXP-517 à la fin du transfert, au contrôle de taille et à la tentative de publication. Le monitoring mesure notamment la latence entre dépôt confirmé et renommage confirmé. Le seuil d’alerte est convenu avec le destinataire selon sa cadence ; il n’est pas déduit des 39 octets du laboratoire. Le runbook désigne qui examine la source, les chemins ou la permission. Cette observabilité doit rendre le dossier attribuable lorsque le transfert paraît terminé mais que le lecteur continue de travailler sur une ancienne version.
Faire survivre les reçus au redémarrage du worker
Le contrat de reprise indique ce qui est enregistré avant le dépôt et après chaque retour exploitable. Une queue ne doit pas reconstruire les chemins à partir du seul nom commercial du fichier. Les retries du worker retrouvent la tentative, la révision et la décision déjà prise. Le rollback du connecteur prévoit la lecture de ces reçus et les publications restées incertaines. Sans persistance, l’empreinte locale et les gardes du programme disparaissent avec son processus ; leurs contrôles ne constituent donc pas un mécanisme de reprise après crash déjà réalisé.
La recette connectée conserve un ancien fichier final, ouvre un lecteur pendant la publication et interrompt le retour du renommage pour observer les comportements réels. Elle vérifie aussi une source remplacée sous le même nom et une extension refusée, sans imposer la suppression de l’ancien document. Pour une autre destination, la finalisation multipart d’un export S3 et la validation des blocs Azure Blob suivent des contrats différents. Le résultat d’une opération ne doit pas être transposé d’un fournisseur à l’autre simplement parce que tous transportent des fichiers.
Conclusion : le renommage mérite son propre diagnostic de livraison
Pour EXP-517, confirmer le dépôt temporaire ne suffit pas à dire que le destinataire lit la révision r2. Le type de renommage, les chemins et l’interprétation du refus déterminent la reprise possible. Les 76 contrôles du laboratoire rendent ces différences observables, tout en laissant au test sur votre service les preuves de droits, de contenu, de stockage et de consommation qui dépendent de l’installation réelle.
Notre offre de middleware sur mesure autour des échanges SFTP permet de cibler une publication interrompue et son destinataire. Nous examinons le client, le transfert et la règle de remplacement pour choisir une reprise explicable. Un refus générique reste à qualifier ; un succès de protocole reste à rapprocher du fichier réellement attendu.
Notre équipe peut cadrer l’intégration API et fichiers reliée à vos logiciels métier autour d’un reçu durable et d’une procédure utilisable par le support. Avec votre intégrateur ERP, nous retenons d’abord une extraction et les preuves attendues. L’extension aux autres échanges vient après cette recette, lorsque le responsable du flux sait quelle tentative reprendre et quelle référence peut être remise au consommateur.
