Salut Christophe, Pour répondre à tes questions: Le répertoire doit être créé au préalable sur le serveur, ce qui doit se faire en dehors de Galaxy. Je pense qu'il serait possible de gérer la création de répertoire en utilisant la ligne suivante: <command interpreter="bash">example.sh -i $input -o $output; #if ! -e $output_dir: mkdir $output_dir #end if; mv $output $output_dir/${file_name}.txt 2>/dev/null;ln -s $output_dir/${file_name}.txt $output</command> On ajoute donc #if ! -e $output_dir: mkdir $output_dir #end if; (ou quelque chose approchant), qui nous permet de tester l'existence du répertoire et le cas échéant de le créer. Effectivement, si un utilisateur utilise le même path et le même nom de fichier que pour une analyse précédente, il va écraser le fichier existant (ce qui reste parfaitement logique). Par contre les liens symboliques ne peuvent pas être écraser puisque l'on réutilise l'identifiant unique dataset_xxx créer par Galaxy. Donc dans le cas cité plus tôt, on va créer deux liens symboliques pointant vers le même fichier. Le lien symbolique ne sera pas indiqué dans les infos du dataset comme c'est le cas pour un dataset créé via les librairies avec utilisation des liens symboliques (ça doit être possible en modifiant à la volée les infos sur le dataset, mais je ne me suis pas penché la dessus). Par contre, pour ce qui est du nom du dataset dans l'historique et les infos, une façon très simple d'attribuer le nom de fichier donné par l'uitlisateur est la suivante: <!-- Output directory--> <param name="file_name" type="text" size="150" label="File name (without extension)"> <validator type="empty_field" message="You must specify a file name"/> </param> <param name="output_dir" type="text" size="150" label="Output directory"> <validator type="empty_field" message="You must specify an output path"/> </param> <!----> </inputs> <outputs> <!-- Attribution d'un label "parlant" à notre output--> <data format="txt" name="output" label="${file_name}"/> </ouputs> Ici, on attribue à notre output un label correspondant au nom de fichier donné par l'utilisateur en utilisant la variable ${file_name} (ce qui permet d'un peu plus s'y retrouvé dans l'historique). L'idée chez nous n'était pas de créer des dossiers personnels de travail, mais de faire fitter Galaxy sur l'arborescence projet structurée déja en place. De cette façon, nos données sont correctement rangées dans les diférents répertoires projets sans perdre la structuration des données en historique au niveau de Galaxy. Un autre avantage est que l'on peut découpler le stockage des données du serveur web faisant tourner Galaxy puisque le répertoire database de Galaxy ne va finalement contenir que des liens symboliques. On se retrouve en effet avec deux niveaux de structuration, mais comme le niveau Galaxy est parfaitement gérer par l'appli elle même.. Par contre, je conseillerais d'utiliser ce genre de tip sur une instance de Galaxy ou les jobs sont lancés "en tant que l'utilisateur courant", sinon, si le user applicatif du serveur web est toujours le même (par défaut) et qu'il possède plus de droits qu'un utilisateur Lambda, il devient difficile de contrôler les écritures et n'importe qui peut écrire n'importe où du moment que le user applicatif a les droits. D'ailleurs, lancer des jobs dans Galaxy en tant que l'utilisateur courant sera certainement l'objet de mon prochain mail sur la liste. J'ai déja une solution à proposer (en place chez nous et parfaitement fonctionnelle), mais elle est quelque peu brutale.. J'espère donc que d'autres personnes auront trouvé des solutions plus "propre" qu'ils pourront nous exposer.. ++, Alban -- Alban Lermine Unité 900 : Inserm - Mines ParisTech - Institut Curie « Bioinformatics and Computational Systems Biology of Cancer » 11-13 rue Pierre et Marie Curie (1er étage) - 75005 Paris - France Tel : +33 (0) 1 56 24 69 84