Gestion des dossiers¶
Résumé¶
Lors d’un transfert, l’utilisateur ne renseigne que la fin du chemin du fichier à transférer. Le début de ce chemin est calculé par Waarp Transfer en fonction des configurations :
de Waarp Transfer, commune à tous les transferts
du serveur, commune à tous les transferts vers/depuis ce serveur (non-valable pour les transferts clients)
de la règle, commune à tous les transferts utilisant une même règle
Les chemins plus spécifiques ont la priorité sur les chemins plus globaux.
Avertissement
Les chemins locaux, distants et temporaires d’une règle ne doivent pas être confondu avec le path de cette règle. Celui-ci sert uniquement à des fins d’identification de le règle, et n’intervient donc pas dans le calcul des chemin de fichiers.
Exemple
Prenons l’exemple d’un transfert entrant où transfer agit comme serveur. Le fichier à transférer est file.txt. Suivant les valeurs des différentes configurations, le chemin de destination du fichier changera comme il suit :
Dossier racine de Transfer |
Dossier “in” de Transfer |
Dossier racine du serveur |
Dossier de réception du serveur |
Dossier local de la règle |
Chemin final du fichier |
---|---|---|---|---|---|
/root |
in |
/root/in/file.txt |
|||
/root |
/in |
/in/file.txt |
|||
/root |
/in |
serveur |
/in/serveur/file.txt |
||
/root |
/in |
/serveur |
/serveur/file.txt |
||
/root |
/in |
/serveur |
serv_recv |
/serveur/serv_recv/file.txt |
|
/root |
/in |
/serveur |
/serv_recv |
/serv_recv/file.txt |
|
/root |
/in |
/serveur |
/serv_recv |
rule_local |
/serv_recv/rule_local/file.txt |
Les transferts sortants fonctionnent de façon similaire, mais en remplaçant le dossier in de Transfer par son dossier out; et en remplaçant le dossier de réception du serveur par son dossier d’envoi.
Les transferts client fonctionne également de façon similaire, mais sans les dossiers spécifiques au serveur.
Explications détaillées¶
Dossiers transfer¶
Toute instance de Waarp Transfer possède un dossier racine (appelé
TransferHome
) que l’utilisateur doit renseigner dans le fichier de
configuration. Par défaut, si l’utilisateur n’a pas renseigné de racine, le
dossier courant est utilisé. Par défaut, tous les chemins non-absolus seront
relatif à cette racine.
C’est également dans le fichier de configuration que nos 3 dossiers mentionnés
plus haut sont définis, respectivement avec les options : le dossier “in”
(DefaultInDir
), le dossier “out” (DefaultOutDir
), et le dossier
temporaire (DefaultTmpDir
). Lors d’un transfert, si aucun chemin plus
spécifique n’est renseigné, ces dossiers seront utilisés localement comme source
ou destination du fichier.
Par défaut, les valeurs “in”, “out” et “work” leur sont respectivement attribuées. Ces chemins sont relatifs à la racine mentionnée plus haut. Il est également possible de renseigner un chemin absolu si l’utilisateur ne souhaite pas que un ou plusieurs des dossiers se trouvent sous la racine.
Dossiers de serveur¶
Lors de la création d’un serveur local, il est possible de
renseigner une racine au serveur (attribut root
), ainsi que des sous-dossier
de réception (receive
), d’envoi (send
), et de réception temporaire
(tmpReceive
).
La racine peut être un chemin absolu ou relatif. Dans le second cas, le chemin sera relatif à la racine de Waarp Transfer. De même, les sous-dossiers peuvent être absolus ou relatif, auquel cas, il seront relatif à la racine du serveur.
Étant rattachés à un serveur local, ces dossiers ne sont utilisés que pour les transferts où l’instance Waarp Transfer agit comme serveur. Si les dossiers d’un serveur sont absolus, ils supplantent les dossiers globaux de Waarp Transfer lors du calcul de chemin du fichier.
Dossiers de règle¶
À la création d’une règle de transfert, il est possible d’attribuer des dossiers
spécifiques à cette règle. Ces dossier comprennent: un dossier local (local
)
sur l’instance Waarp Transfer, un dossier distant (remote
) sur le(s)
partenaire(s), et un dossier local temporaire (tmpLocal
).
Tous les fichiers transférés avec cette règle utiliseront donc ces dossiers. Pour les règles d’envoi, les fichiers seront toujours récupérés depuis le dossier local, puis déposés dans le dossier distant. À l’inverse, dans le cas des règles de réception, les fichiers seront toujours récupérés depuis le dossier distant, puis déposés dans le dossier temporaire local, avant d’être ensuite déplacés dans le dossier de réception une fois le transfert terminé.
Ces dossier peuvent être des chemins absolus ou relatifs. Dans le second cas, si Waarp Transfer agit comme client du transfert, ce chemin est alors relatif à la racine. En revanche, si Waarp Transfer est serveur du transfert, alors tout chemin relatif est considéré comme relatif à la racine du serveur local, s’il en a une, ou bien à la racine de Waarp Transfer s’il n’en a pas.
Instances cloud¶
Au lieu de stocker les fichiers de transfert sur le disque local de la machine sur laquelle est installée Waarp Transfer, il est possible, à la place, de les stocker sur une machine distante (en générale, une instance cloud).
Pour cela, l’instance cloud doit préalablement avoir été renseignée dans Waarp Transfer (voir la commande de gestion des instances clouds ou le handler REST de gestion des instances cloud). Une fois l’instance cloud définie, il est possible de la référencer dans les divers chemin décrits ci-dessus.
Ainsi, il est donc possible de définir une règle ayant comme dossier « local » un dossier se trouvant sur une instance cloud. De même, il est possible de définir un serveur ayant pour racine une instance cloud.
Il est à noter cependant que, étant donné que les certains types d’instance cloud ne supportent pas toutes les actions requises par Waarp Transfer, certains type d’instances cloud ne peuvent pas être utilisé dans certains contexts. Voir la section cloud pour avoir plus de détails.
Pour référencer une instance cloud, la syntaxe est :
instance_cloud:chemin/du/fichier
Note
Il est à noter que, étant donné que les instances cloud agissent comme alternatives au disque de stockage local, l’envoi ou la réception d’un fichier sur/depuis une instance cloud n’est pas considéré comme un transfert; de la même manière que l’écriture ou la lecture d’un fichier sur le disque local n’est pas considérée comme un transfert.
Exemples
Par exemple, si je souhaite accéder au fichier « baz » qui se trouve dans le dossier « foo/bar » de l’instance cloud nommée « toto », le chemin à utiliser sera donc la suivante :
toto:foo/bar/baz
Si je souhaite accéder au dossier « wt/out » de l’instance cloud Azure nommée « titi », le chemin à utiliser sera la suivante :
titi:wt/out