Notes de version
Cette version contient 3 améliorations et plus de 6 correctifs.
Principale nouveauté
Il arrive qu’il soit nécessaire de démarrer un transfert et de démarrer un transfert pour un fichier qui sera généré en tâche pré-transfert.
Ce cas d’usage est désormais supporté par Waarp Gateway.
Par exemple, si on souhaite transférer l’intégralité d’un dossier a.envoyer dans une archive zippée, il est possible de lancer le transfert du fichier a_envoyer.zip, et de paramétrer en pré-transfert la tâche EXEC avec la commande zip-dossier.sh #ORIGINALFILENAME#, et le script zip-dossier.sh suivant:
#!/usr/bin/env bash
zip -r $1 ${1%.zip}
Liste des Changements
Nouvelles fonctionnalités
- #374 Ajout de 2 colonnes src_filename et dest_filename aux tables des transferts et d’historique. Ces colonnes contiennent respectivement (lorsque c’est pertinent) le nom de fichier source, et le nom de fichier destination du transfert. Contrairement aux colonnes local_path et remote_path déjà existantes, le contenu de ces 2 nouvelles colonnes ne change jamais, même lorsque le nom du fichier est modifié durant le transfert. Par conséquent, les noms de fichiers src_filename et dest_filename contiennent toujours le nom de fichier tel qu’il a été donné dans la requête originale.
- #375 Il est désormais possible de commencer un transfert d’envoi même si le fichier à envoyer n’existe pas encore, tant que celui-ci est créé avant le début de la phase d’envoi des données. Typiquement, cela permet de démarrer un transfert où le fichier est créé via les pré-tâches.
- Les logs des tâches (notamment des tâches EXEC) ont été améliorés. Dans le cas des tâches EXEC, la sortie standard du programme externe est désormais récupérée et écrite dans les logs de la gateway (au niveau DEBUG).
Correctifs
- #374 Les transferts créés avec un chemin de fichier absolus déposaient le fichier au mauvais endroit,
- #374 Si le nom du fichier changeait durant le transfert, et que le transfert en question était ensuite reprogrammé (via la commande waarp-gateway transfer retry), le transfert échouait systématiquement avec une erreur « file not found »,
- #376 Correction d’un bug du client R66 de Gateway qui empêchait celui-ci récupérer un fichier depuis un agent Waarp R66 pour cause de « mauvais chemin de fichier »,
- #376 Correction également d’un bug de compatibilité avec les agents Waarp R66 qui pouvait causer un crash de Gateway dans certaines circonstances,
- #377 Suppression de la limite de temps de 2 secondes imposée par le script updateconf pour réaliser un import de configuration. Cette limite de temps causait l’échec de l’import lorsque celui-ci prenait plus de 2 secondes à se compléter.
Par ailleurs, la commande d’import a été optimisée pour réduire la durée pendant laquelle la transaction avec la base de données est active. Cela permet d’éviter les conflits entre transactions qui peuvent se produire lorsqu’une transaction reste ouverte trop longtemps.