Les règles du matériel pédagogique · Règle 4

Une URL Drive se convertit en chemin local

Une adresse Google Drive n'est pas un endroit où travailler : on la traduit d'abord en chemin local sur le montage, par un script qui part de l'identifiant, jamais en cliquant.

Une adresse Google Drive reçue dans une consigne se convertit en chemin local (le dossier monté sur la machine) avant tout travail : c'est là que les outils lisent, écrivent, comparent et publient. La conversion part de l'identifiant, pas du nom, et se fait par un script, jamais en remontant l'arborescence à la main dans l'interface web. Le chemin trouvé s'écrit dans le document, à côté de l'adresse.

Le cas qui a donné la règle

Une adresse de dossier Google Drive arrive dans une consigne : « peux-tu me dire le chemin local de ce dossier ? ». Le dossier s'appelle procedure-firestore-ocean : vingt-cinq captures d'écran d'une procédure de configuration et un fichier de dépendances, datés de 2020. L'interface web montre le dossier et son contenu, mais pas sa place dans un Drive de cours qui compte plus de seize mille dossiers, monté localement par rclone.

Première surprise : rclone sait lister tout un Drive avec les identifiants, mais ne sait pas remonter d'un identifiant vers un chemin. Deuxième surprise : deux dossiers portent exactement ce nom dans le même Drive, l'un de 2020 et l'autre de 2022. Chercher par nom aurait donné une réponse plausible et fausse une fois sur deux. Troisième surprise : la chaîne des parents remontée par l'API (le dossier, puis « Exercice & Solution », puis « Semaine 8 ») s'est cassée au niveau au-dessus, invisible pour le compte qui interrogeait l'API alors que le montage, lui, y avait accès.

La réponse est venue de l'index complet des dossiers avec leurs identifiants, construit en quelques minutes, dans lequel l'identifiant se cherche en une fraction de seconde :

1KxuNkw…ndLI;==COURS XYZ==/BaseDonneesClientServeur/Semaines/Semaine 8/Ocean - Exercice & Solution/procedure-firestore-ocean/
Le résultat

Le chemin local, vérifié par un listage du dossier et par l'identifiant relu sur le dossier parent. Vingt minutes d'outillage la première fois ; un script gardé dans le répertoire du cours pour que la deuxième fois coûte une commande. C'est la personne qui a reçu la réponse qui a demandé la règle : « les URL Drive doivent être converties en chemin local ».

Pourquoi

Les outils travaillent sur des fichiers, pas sur des adresses. Compter les pixels d'une diapositive, mesurer un libellé, générer une vignette, recopier une commande dans une fiche : tout ce que les autres règles demandent se passe sur le montage local. Une URL Drive dans une consigne est une étape de moins que le lecteur a franchie, ce qui contredit l'auto-portance (règle 1).

L'identifiant est la seule chose stable. Un dossier peut être renommé, déplacé, dupliqué ; son identifiant ne change jamais. Deux dossiers homonymes dans le même Drive, c'est la norme dans du matériel de cours qui vit depuis des années (« Semaine 8 » existe dans chaque cours). La conversion part donc de l'identifiant, et se confirme par l'identifiant.

La deuxième fois doit coûter une commande. Remonter l'arborescence en cliquant dans l'interface web marche, une fois, pour une personne. Un script marche pour toutes les adresses à venir, pour tous les Drives montés, et pour l'assistant qui n'a pas d'interface web sous les yeux.

Comment l'appliquer

1. Extraire l'identifiant

L'identifiant est la longue suite de lettres, de chiffres, de tirets et de soulignés de l'adresse, qu'elle soit de la forme /drive/folders/ID, /file/d/ID/view ou ?id=ID. Le script le fait seul, on peut lui donner l'adresse entière.

2. Convertir par le script

trouver-chemin-local-drive.sh "https://drive.google.com/drive/folders/1KxuNkw…ndLI" nadineducegep

Sans nom de Drive, le script essaie tous les Drives montés. La première fois, il demande à l'API la liste de tous les dossiers du Drive avec leur parent (une page par mille dossiers, environ une minute pour dix mille) et la garde en cache ; ensuite chaque conversion prend une fraction de seconde. Le chemin se reconstruit en remontant les parents en mémoire, sans jamais parcourir l'arborescence. Si l'adresse est celle d'un fichier, on ajoute --nom "nom exact du fichier" : l'API ne cherche pas un fichier par identifiant, mais elle le trouve par nom et rend son dossier.

3. Vérifier le chemin et l'identifiant

ls "/DRIVE/nadineducegep/…/procedure-firestore-ocean"
rclone lsf --dirs-only --format "ip" "nadineducegep:…/Ocean - Exercice & Solution/"

La deuxième commande relit les identifiants des dossiers du parent : celui de l'adresse doit y être, devant le bon nom. C'est ce qui départage deux homonymes.

4. Écrire le chemin dans le document

Le chemin local trouvé va dans la consigne, la fiche ou la note de projet, à côté de l'adresse Drive. Le prochain lecteur, humain ou assistant, ne refait pas la conversion.

Avant de commencer le travail
  • Le Drive est monté (le point de montage répond à un ls).
  • Le chemin local existe et son contenu correspond à ce que l'interface web montre.
  • L'identifiant de l'adresse est relu sur le dossier parent, devant le bon nom.
  • Le chemin est écrit dans le document qui portait l'adresse.

Les pièges

Chercher par nom

Le nom d'un dossier n'est pas unique, même dans un seul Drive. Le cas fondateur avait deux procedure-firestore-ocean ; une recherche par nom aurait renvoyé le mauvais sans prévenir. On cherche l'identifiant, on confirme l'identifiant.

Le compte de l'API n'est pas le compte du montage

Un outil branché sur un autre compte Google voit le dossier partagé mais pas ses ancêtres : la chaîne des parents s'arrête sur « entité introuvable ». La vérité, c'est le compte qui a monté le Drive. On interroge rclone, pas un autre compte.

L'index vieillit

Un dossier créé après la construction de l'index n'y est pas. Le script redemande la liste quand l'identifiant manque et que le cache a plus de dix minutes ; l'option --rafraichir force la reconstruction.

Parcourir l'arborescence

La première version du script parcourait le Drive dossier par dossier : plus d'une heure pour cent mille dossiers, et l'option de listage rapide gardait tout en mémoire jusqu'à mettre la machine à genoux. Une seule requête à l'API qui rend tous les dossiers avec leur parent fait le même travail en une minute par dix mille dossiers, et la remontée se fait en mémoire. Quand une méthode ne passe pas à l'échelle du Drive, on change de méthode, pas de patience.

Le montage n'affiche qu'un dossier par nom

Google Drive accepte deux dossiers « art » dans le même parent ; un système de fichiers, non. Le montage n'en affiche qu'un, et l'autre, avec tout son contenu, n'existe pas localement. Le chemin reconstruit avec les noms de l'API est alors juste et pourtant introuvable. Le script compare le contenu du dossier affiché avec ce que l'API donne pour le dossier visé et le dit quand ce n'est pas le bon ; la seule issue est de renommer un des deux sur drive.google.com. Un chemin reconstruit se vérifie par un listage, jamais par sa seule vraisemblance.

Deviner à partir du contenu

« Un dossier Firestore, ça doit être dans le cours de bases de données » est une hypothèse, pas une réponse. Elle se vérifie par l'identifiant ou elle ne vaut rien.

Où c'est transposable

Tout stockage en nuage monté localement pose la même question : une adresse OneDrive, Dropbox ou Nextcloud reçue dans une consigne se traduit en chemin sur le montage avant qu'on y touche, et la traduction part de l'identifiant que le service donne à l'objet, pas de son nom. Un lien vers une « Semaine 8 » dans une page de cours note aussi son chemin local dans le dépôt du cours.

Fichier de référence : ECOLE/INFOCOMMUNICATION/trouver-chemin-local-drive.sh (copie dans /TOOLS/classification/scripts/). Il lit les Drives montés, extrait l'identifiant, demande la liste des dossiers à l'API, la met en cache, remonte les parents et rend le chemin local.