En résumé
Un entrepôt de 40 Go n’a pas à transiter par le navigateur : posez-le sur le serveur, et Linkr le désigne par son chemin — rien n’est copié. Le rôle de l’administrateur est de délimiter ce que ce sélecteur peut atteindre, avec LINKR_FS_BROWSE_ROOTS. Par défaut, aucune limite n’est posée : c’est au déploiement de ne monter que ce que le serveur doit voir.
Le problème que cela résout
Tout point d’entrée « fichier » d’une application web suppose que le fichier est sur le poste de l’utilisateur. Pour une base DuckDB ou un dossier Parquet qu’un administrateur a déposé sur le serveur, cela oblige à un détour absurde : télécharger le fichier sur son poste pour le re-téléverser. Au-delà de la taille maximale d’envoi, c’est même impossible.
Désigner un chemin serveur supprime le détour. Rien ne bouge : Linkr lit les fichiers là où ils sont.
Trois origines de fichier, à ne pas confondre
Le téléversement reste la bonne réponse pour les petits fichiers d’auteur — une archive d’import, une image, un script. Le chemin serveur est fait pour les gros volumes de données. Il existe aussi, en mode navigateur, un accès direct aux dossiers de votre poste, sans copie : c’est l’équivalent côté client. Les deux répondent au même besoin — ne pas dupliquer des gigaoctets — chacun de son côté.
Où cela s’utilise
| Écran | Ce qu’on désigne |
|---|---|
| Bases de données › Ajouter | Un fichier .duckdb ou .sqlite, ou un dossier de fichiers Parquet. |
| IDE › Connexions | La même chose, depuis l’environnement de code du projet. |
| Alignement de concepts › Vocabulaire | Un dossier de vocabulaire OHDSI — plusieurs gigaoctets, une dizaine de tables. |
| Projet › Dossiers | Les trois emplacements du projet : dossier de travail de l’IDE, sous-dossier de code, dossier des jeux de données. |
Dans les dialogues d’ajout de base, une option Fichier serveur apparaît à côté du téléversement, avec pour indication « Cliquez pour parcourir le serveur ». S’ouvre alors un navigateur de fichiers côté serveur.
Ailleurs, le téléversement reste seul
Les autres points d’entrée — import d’archives, pièces jointes, fichiers de l’IDE — n’acceptent que le téléversement. C’est délibéré : ces fichiers viennent du poste de l’utilisateur, et ajouter un onglet « serveur » partout n’aurait rendu service nulle part.
Délimiter ce qui est atteignable
C’est la décision d’administration de cette page, et elle mérite d’être prise explicitement.
Par défaut, le sélecteur voit tout le système de fichiers
Sans configuration, LINKR_FS_BROWSE_ROOTS est vide et aucune racine n’est imposée : le sélecteur peut parcourir l’ensemble du système de fichiers visible par le serveur. C’est le modèle de RStudio Server — le confinement est la responsabilité du déploiement : on ne monte dans le conteneur que ce que le serveur doit voir.
Si votre serveur voit plus que cela, posez des racines.
La variable prend une liste de chemins absolus séparés par des virgules :
LINKR_FS_BROWSE_ROOTS="/data/warehouse,/data/vocabularies"Le sélecteur ne sort alors plus de ces dossiers, ni de leurs sous-dossiers.
Ce qui est vérifié, et à quel moment
Trois protections se cumulent, et la dernière est la plus importante.
Un droit est exigé
Parcourir le serveur n’est pas ouvert à tous : désigner la source d’une base demande le droit de modifier les bases, et lier les dossiers d’un projet celui d’en modifier les paramètres.
Les liens symboliques sont résolus
Un chemin est résolu avant d’être comparé aux racines : un lien symbolique ne permet donc pas de sortir d’une racine autorisée.
La limite est revérifiée à l’enregistrement
La vérification faite dans le sélecteur n’est qu’un confort d’interface. Elle est refaite au moment où le chemin est enregistré — c’est ce qui empêche de contourner le sélecteur en envoyant directement un chemin arbitraire.
Ce que cela ne permet pas
- Écrire n’importe où. Une base désignée par son chemin est ouverte en lecture seule, et ne peut pas servir de cible à un pipeline ETL.
- Faire fuiter le chemin dans un export. Le chemin serveur est retiré des exports, comme les autres informations de connexion : une entité partagée ne révèle pas l’arborescence de votre serveur.
- Lier les dossiers d’un projet sans l’IDE. Si l’exécution de code est désactivée sur l’instance, les liaisons de dossiers le sont aussi. Désigner une base, en revanche, reste possible : attacher des données en lecture n’est pas exécuter du code.
Un vocabulaire sur le serveur se lit en Parquet
Un dossier de vocabulaire désigné sur le serveur est lu au format Parquet. Un export OHDSI en CSV est refusé avec un message explicite plutôt qu’importé à vide — mieux vaut un refus lisible qu’un import silencieusement incomplet.
Les dossiers d’un projet
Un projet expose trois emplacements réglables séparément, décrits dans ses paramètres :
- Le dossier de travail de l’IDE — ce que l’explorateur de fichiers affiche, et où démarrent les terminaux et les sessions R et Python.
- Le sous-dossier de code — la partie empaquetée à l’export et au versioning. Réglé à part précisément pour qu’un export n’emporte jamais des jeux de données situés ailleurs dans le dossier de l’IDE.
- Le dossier des jeux de données — accessible depuis les scripts par une variable d’environnement.
Les trois sont indépendants et propres à la machine : ils ne partent pas dans un export, et une autre installation utilisera les siens.
Conséquence pour vos utilisateurs
Comme ces dossiers sont repositionnables, un script ne doit jamais déduire un emplacement d’un autre — écrire ”../datasets” fonctionne jusqu’au jour où quelqu’un déplace un dossier. Les bibliothèques linkr fournissent les accesseurs à utiliser. Voir IDE.
Pour aller plus loin
- Configuration — les autres variables d’environnement d’une instance.
- Authentification et permissions — quels droits ouvrent ce sélecteur.
- Bases de données — le point de vue de l’utilisateur sur les mêmes écrans.
- IDE — les dossiers du projet, vus depuis le code.