Toutefois, si l'utilisateur confirme en cliquant sur « Lancer », le lancement échoue avec un message énigmatique « impossible de trouver le programme de lancement automatique ».
Depuis plusieurs années, l'auteur de cette page utilise pour son travail un disque externe USB qui est régulièrement connecté à plusieurs ordinateurs sous GNU/Linux (Ubuntu, Suse) et, de temps en temps, également exploité avec des ordinateurs sous Windows. Il doit donc être formaté par un système de fichiers FAT ou NTFS compréhensible par ce dernier car GNU/linux sait les lire, l'inverse n'étant pas vrai.
Le contenu de ce disque étant important, il doit être régulièrement sauvegardé. La nature humaine étant ce qu'elle est, le choix a été fait de doter le disque d'un système de rappel automatique proposant de lancer la sauvegarde (avec une périodicité fixée à l'avance) et l'effectuant si l'utilisateur confirme, quel que soit l'ordinateur sous GNU/Linux utilisé. Ce dispositif est très simplement constitué de deux fichiers contenant des scripts bash et bien sûr dotés des droits d'exécution : autorun.sh et sovgarde.sh. Le deuxième est celui qui effectue les tests et traitements fonctionnels de sauvegarde désirés. Le premier contient une seule action lançant automatiquement le second lors du branchement à chaud du disque externe. Séparer l'action en deux fichiers permet de lancer le second manuellement si nécessaire. Ceci a fonctionné sans faille jusqu'à Lucid Lynx. Malheureusement, sous Pangolin, cela ne fonctionne plus. Il a donc fallu se pencher sur les entrailles du système pour en savoir plus.
Pour le besoin des tests, le dispositif de lancement automatique est modélisé par deux fichiers simples :
#!/bin/bash
/bin/bash ./testauto.sh
#!/bin/bash
VARIABLE="Ce script fonctionne parfaitement !"
zenity --info --text "$VARIABLE"
Pour mémoire, zenity est le logiciel permettant aux scripts d'afficher leurs sorties dans des fenêtres de l'interface graphique.
Le noyau linux permet depuis longtemps à l'administrateur de lire un système de fichiers NTFS mais c'est seulement depuis 2006 qu'un pilote libre nommé ntfs-3g a été développé pour permettre à tout utilisateur de lire et d'écrire dans des partitions NTFS. Ce pilote est maintenant stable et assez complet pour être utilisé sans crainte.
Lorsqu'un disque USB est branché à chaud sous Ubuntu « Precise Pangolin »,
il est monté automatiquement mais, malheureusement (et ce n'était pas le cas sous « Lucid Lynx »),
sans recevoir les droits d'exécution permettant aux scripts bash embarqués de s'exécuter. Le système annonce alors correctement
qu'un périphérique comportant un autoexécutable a été monté et demande bien à l'utilisateur s'il souhaite le lancer.
Toutefois, si l'utilisateur confirme en cliquant sur « Lancer », le lancement échoue avec un message énigmatique
« impossible de trouver le programme de lancement automatique ».
Ce problème peut se résoudre facilement (merci à clintonio) en obligeant explicitement le processus udev qui monte le disque USB à utiliser le pilote ntfs-3g. Ceci s'obtient en créant une règle qui va se substituer au choix par défaut de udev. Pour cela, il suffit de créer, avec les droits de superutilisateur, dans le dossier /etc/udev/rules.d, un fichier portant un nom assurant qu'il sera lu en dernier par udev, par exemple 99-usb-disks.rules, contenant la ligne suivante.
ENV{ID_FS_TYPE}=="ntfs", ENV{ID_FS_TYPE}="ntfs-3g"
Comme ces règles sont lues dynamiquement, il n'est pas nécessaire de relancer la session. Si le disque est en cours
d'utilisation, le démonter et le débrancher. Le rebrancher, cette fois les fichiers devraient avoir les droits nécessaires
et le lancement automatique devrait fonctionner.
Si le périphérique usb a été formaté avec le système de fichiers FAT 16 ou FAT 32, c'est moins simple.
En effet, sous « Precise Pangolin », le périphérique est monté automatiquement en système de fichiers vfat, avec une option showexec qui fait considérer tous les fichiers de texte comme non exécutables, sauf s'ils portent l'extension BAT (les EXE et COM sont aussi exécutables). Comme les scripts ne portent pas cette extension, l'utilisateur est confronté au même message « impossible de trouver le programme de lancement automatique ».
Malheureusement, pour une raison difficile à comprendre, il semble que l'imposition de cette option showexec soit codée en dur dans le binaire de l'utilitaire qui monte le périphérique, à savoir /usr/lib/udisks/udisks-daemon.
Plusieurs solutions sont imaginables. Les experts pourront recompiler le paquets udisks à partir des sources. Ou bien, il est sans doute également possible d'écrire des règles udev qui démontent le périphérique et le remonte sans l'option showexec (non investigué).
L'auteur a plus simplement appliqué une modification directe du binaire exécutable pour en retirer toutes les occurrences de la chaîne de caractères « showexec », empêchant ainsi le « démon » d'imposer cette option, en suivant la méthode suggérée par Pronobo, soit :
sudo sed -i -e 's|showexec|\x00\x00\x00\x00\x00\x00\x00\x00|g' /usr/lib/udisks/udisks-daemon
Voilà, la manipulation n'a pris que quelques minutes et, au prochain branchement du périphérique, cela devrait marcher. La commande « magique » a eu pour effet de remplacer partout dans le fichier
binaire les huit caractères showexec par autant de caractères nuls. En principe, ceci permet de ne pas compromettre le fonctionnement de l'utilitaire.