Brevet FR2923924A1 — publié le 20090522

Procédé et dispositif de détection et de résolution d'un conflit dans la gestion des périphériques d'un ordinateur. Arrière-plan de l'invention L'invention se situe dans le domaine des équipements périphériques d'une station hôte. Au sens de l'invention, une station hôte peut être un ordinateur personnel, portable ou fixe, un terminal de travail relié à un serveur, un ordinateur de poche, un téléphone mobile ou, de façon générale, tout autre appareil électronique de traitement de données. Dans ce document, il faudra prendre soin de bien distinguer les périphériques de stockage (disques, CD-ROM, clés USB, cartes mémoires,...) auxquels peut être associé un nom de volume, des autres types de périphériques (cartes réseau, claviers, écrans, imprimantes, scanners,...). De façon connue, un "nom de volume" correspond à un périphérique logique, par opposition à la terminologie "device" qui, elle, désigne un périphérique physique. A titre d'exemple, une clé USB est un "device". Elle peut contenir plusieurs partitions, chacune d'entre elles étant associée à un nom de volume logique. L'invention vise plus particulièrement un procédé pour détecter et résoudre des conflits dans la gestion des lecteurs réseau d'une station hôte. De façon connue, un "lecteur de réseau" est associé à un disque réseau, étant rappelé qu'un disque réseau n'est pas un périphérique physique de stockage à proprement parler. Afin de bien illustrer le problème technique que se propose de résoudre l'invention, on peut se reporter à la note publiée sur le site Internet de la société Microsoft (marque déposée) à l'adresse http://support.microsoft.com/kb/306819/fr : "Les noms des lecteurs de périphériques locaux (une lettre de l'alphabet) sont généralement attribués de façon incrément/elle à partir de la lettre C et les noms de lecteurs réseau sont automatiquement attribués à partir de la lettre Z, dans l'ordre inverse (Z, Y, etc). Des conflits de lettres de lecteurs avec les partages réseaux existants peuvent survenir lorsque vous connectez des appareils photos numériques et autres périphériques utilisant des M6mo/y Sticks à Windows XP tandis que l'ordinateur est allumé. Le même conflit peut survenir lorsque vous ajoutez des lecteurs externes (tels que des disques USB ou 1394). Dans le cas d'un conflit d'attribution de noms avec un partage réseau existant, le périphérique local ne sera pas accessible. Pour contourner ce problème, autorisez Windows à affecter 10 automatiquement les noms de lecteurs réseau ou à choisir les lettres des noms de lecteurs ultérieures dans l'alphabet'. Un tel conflit dans la gestion des volumes logiques associés aux périphériques est très dommageable puisqu'il peut, dans certains cas, bloquer l'utilisation du périphérique concerné. 15 Objet et résumé de l'invention L'invention concerne un procédé de détection et de résolution d'un conflit susceptible de se produire lorsqu'on connecte un périphérique à une station hôte. 20 Ce procédé comporte : une étape d'obtention du nom d'au moins un volume logique connecté à la station hôte ; une étape d'obtention, à partir du nom de volume logique, d'un identifiant unique du volume logique; 25 une étape au cours de laquelle on vérifie si l'identifiant unique du volume logique correspond à une lettre d'un lecteur de la station hôte, un conflit étant détecté en cas d'échec de l'étape de vérification ; et, en cas de conflit : une étape de résolution du conflit au cours de laquelle on affecte une 30 lettre disponible au volume logique. Corrélativement, l'invention concerne un dispositif de détection et de résolution d'un conflit susceptible de se produire lorsqu'on connecte un périphérique à une station hôte comportant : - des moyens d'obtention du nom d'au moins un volume logique connecté 35 à ladite station hôte ; - des moyens d'obtention, à partir du nom de volume logique, d'un identifiant unique du volume logique; des moyens pour vérifier si l'identifiant unique du volume logique correspond à une lettre d'un lecteur de ladite station hôte ; des moyens pour détecter un conflit en cas d'échec de la vérification; et - des moyens pour affecter une lettre disponible au volume logique afin de résoudre le conflit. D'une façon générale, l'invention propose donc de détecter d'éventuels conflits dans la gestion des périphériques d'une station hôte 10 en deux temps: on recherche tout d'abord les noms et types de tous les volumes logiques connectés à la station hôte ; puis on vérifie pour l'ensemble des lettres des lecteurs de la station hôte si le volume logique ainsi trouvé correspond à 15 cette lettre. De façon inhabituelle, l'invention manipule les informations relatives à la gestion des noms de volumes de différents niveaux, certaines d'entre elles étant des informations de � niveau noyau � (couche système), et d'autres des informations de � niveau utilisateur � (couche 20 applicative). On rappelle à cet égard que le noyau fait partie du système d'exploitation d'un ordinateur, son rôle principal étant de gérer les ressources de cet ordinateur et de permettre les échanges entre les différents composants matériels et logiciels. 25 Le noyau fournit aussi un mécanisme d'abstraction du matériel (notamment de la mémoire du ou des processeurs) et de ses propres fonctions logicielles. Mais il est connu que le noyau ne peut pas utiliser lui-même tous les mécanismes d'abstraction qu'il fournit aux autres couches 30 logicielles. Son rôle central et critique lui impose en effet des performances élevées incompatibles avec la lenteur relative induite par ces mécanismes d'abstraction. Par ailleurs, l'existence d'un noyau impose une partition de la mémoire vive physique de l'ordinateur en deux régions disjointes, l'une 35 appelée "espace noyau" étant réservé au noyau et l'autre appelée "espace utilisateur" aux applications. Le procédé de détection et de résolution de conflits selon l'invention, qui utilise à la fois des fonctions du noyau et des fonctions applicatives, offre une solution originale, à l'opposé des techniques classiques de programmation, qui ont pour habitude de ne pas utiliser, dans un même programme ces demandes, à la fois des fonctions de l'espace noyau et de l'espace applicatif, notamment pour des raisons de sécurité. Il est en effet connu que l'appel à des fonctions de l'espace noyau nécessite des mécanismes de protection de la mémoire et de gestion de la sécurité avec des contraintes fortes qui peuvent être ignorées par le programmeur lorsqu'il manipule les fonctions de la couche applicative. L'invention vise également un programme d'ordinateur comportant des instructions pour l'exécution des étapes du procédé de détection et de résolution tel que décrit précédemment lorsque le 15 programme est exécuté par un ordinateur. L'invention vise également un support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur comprenant des instructions pour l'exécution des étapes du procédé de détection et de résolution de conflit tel que décrit précédemment. 20 L'invention vise également une clé USB constituant un tel support d'enregistrement. Dans ce mode de réalisation, le programme d'ordinateur selon l'invention est situé dans une mémoire non volatile de cette clé USB. Dans un mode préféré de réalisation, la clé USB selon l'invention 25 comporte au moins deux volumes logiques, l'un de ces volumes logiques constituant un support d'enregistrement dans lequel est mémorisé le programme d'ordinateur selon l'invention. Il est connu en effet, de partitionner une clé USB en deux volumes logiques appelés "partition mass storage" et "partition CD". Les 30 types de ces partitions sont des types "REMOVABLE" et "CDROM" du système d'exploitation Windows XP. Dans un mode particulier de réalisation du procédé de détection et de résolution de conflit selon l'invention, on obtient également, à partir du nom du volume logique, un type de ce volume logique, l'étape de 35 vérification étant effectuée si ce type est un type prédéterminé. Dans un mode préféré de réalisation du procédé de détection et de résolution de conflits selon l'invention, si on obtient des volumes logiques de plusieurs types on traite les volumes logiques, dans un ordre prédéterminé en fonction de leur type. Par exemple, il est préférable de traiter les volumes de type REMOVABLE avant les périphériques de type CDROM lorsque le programme d'ordinateur selon l'invention est mis en oeuvre par une fonction � autorun � mémorisée sur la partition CDROM de la clef USB, apte à exécuter un programme mémorisé quant à lui sur la partition REMOVABLE. L'homme du métier comprendra qu'en traitant d'abord les volumes logiques REMOVABLE, l'autorun qui se déclenche automatiquement dès que le conflit sera résolu, peut fonctionner correctement. Dans un mode préféré de réalisation, le procédé de détection et de résolution de conflits selon l'invention comporte une étape au cours de laquelle on vérifie si un périphérique d'un modèle prédéterminé est connecté à la station hôte. Les périphériques d'un modèle prédéterminé au sens de l'invention peuvent être les périphériques distribués par un constructeur particulier susceptible d'être connecté à la station hôte. Dans un mode particulier de réalisation, le procédé de détection et résolution de conflits selon l'invention comporte en outre : une étape d'obtention, à partir d'un identifiant du périphérique de modèle prédéterminé d'un numéro séquentiel attribué à ce périphérique par le système d'exploitation de la station hôte ; une étape d'obtention d'un numéro séquentiel attribué par ce système d'exploitation, au périphérique physique monté sur le volume logique en conflit et une étape de comparaison des numéros séquentiels pour déterminer si le périphérique monté sur le volume logique en conflit est un périphérique du modèle prédéterminé. L'étape d'obtention de l'identifiant du périphérique de modèle prédéterminé peut être mise en oeuvre par l'appel d'une fonction du noyau, et l'étape d'obtention du numéro séquentiel attribué au périphérique physique monté sur le volume logique en conflit peut être mise en oeuvre par une fonction du niveau applicatif. Là encore, le procédé de détection et de résolution de conflits selon l'invention fait, de façon originale, appel à deux fonctions classiquement utilisées dans deux domaines de programmation différents, pour vérifier si le périphérique monté sur le volume logique en conflit est du modèle prédéterminé. Dans un mode particulier de réalisation de l'invention, l'obtention de l'identifiant du périphérique de modèle prédéterminé comporte une sous-étape d'obtention de la liste des interfaces de ce périphérique. Lorsque le système d'exploitation de la station hôte est un système d'exploitation Windows de la société Microsoft, il est en effet nécessaire, pour réaffecter une lettre disponible au volume en conflit, de vérifier dans un premier temps à quelle lettre le volume aurait dû être associé en l'absence de conflit. En effet, les interfaces de programmation de l'application (API pour "Application Programming Interface") offertes par le système d'exploitation Windows, demandent que l'on renseigne la lettre précédemment utilisée afin de pouvoir démonter un lecteur réseau. En conséquence, dans un mode particulier de réalisation de l'invention, l'étape de réalisation de conflits comporte : une étape de recherche de la lettre qui aurait été affectée au volume logique en l'absence de conflit une étape au cours de laquelle on démonte le volume logique de l'endroit où il se trouve et une étape au cours de laquelle on monte le volume logique sur la lettre disponible. L'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en oeuvre dans une station hôte ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en oeuvre des étapes d'un procédé de détection et de résolution de conflit tel que mentionné ci-dessus. Ce programme peut utiliser n'importe quel langage de programmation offrant accès aux fonctions nécessaires de l'espace noyau. Ce programme peut être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. On peut notamment utiliser le langage C et le compilateur Visual C++ (marque déposée). L'invention vise aussi un support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy dise) ou un disque dur. D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question. Brève description des dessins - les figures 1A à 1D illustrent un exemple de conflit pouvant être détecté et résolu par l'invention ; - la figure 2 représente, dans son environnement, une clé USB conforme à l'invention dans un mode particulier de réalisation ;et - la figure 3 représente, sous forme d'organigramme, les principales étapes d'un procédé de détection et de résolution de conflits conforme à l'invention dans un mode particulier de réalisation ; et Description détaillée d'un mode de réalisation Nous allons maintenant décrire un mode particulier de réalisation de l'invention pour détecter et résoudre un conflit susceptible de se produire lorsqu'on connecte une clef USB 10 conforme à l'invention à une station hôte 20 dont le système d'exploitation est le système Windows XP (ou Vista) de la société Microsoft. Les figures 1A et 1B représentent l'état de la station hôte 20 5 avant la connexion de la clef USB 10 et les figures 1C et 1D l'état de la station hôte après la connexion de la clef USB 10. La figure 1A est une copie des informations affichées sur l'écran de la station hôte par l'application Windows Explorer connue de l'homme du métier. Les fonctions utilisées par cette application pour obtenir ces 10 informations sont des fonctions de l'espace utilisateur. Dans l'exemple décrit ici, six périphériques de stockage non représentés sont connectés à la station hôte 20 et associés aux lettres A à G. Par ailleurs, la lettre H est affectée à un lecteur réseau. De 15 façon connue, comme le rappelle la note de Microsoft citée dans le préambule de la présente demande, l'affectation pour un lecteur réseau est faite, dans l'espace utilisateur, en parcourant la liste des noms de volumes disponibles en partant de la fin de l'alphabet (Z). Mais l'utilisateur peut choisir d'affecter une autre lettre, par 20 exemple une autre lettre disponible, en l'occurrence ici la lettre H. La figure 1B représente le résultat d'une commande DOS permettant d'obtenir les informations connues du noyau de Windows XP. On remarque que la lettre H associée à un lecteur réseau au niveau utilisateur n'est pas listée par cette fonction DOS, seules les lettres 25 A à G associées à des périphériques de stockage étant connues du noyau. On suppose maintenant que l'on connecte la clef USB 10 dans un port USB 21 de la station hâte 20. De façon connue, le noyau de Windows XP affectera alors la première lettre, par ordre alphabétique, disponible pour les volumes de 30 stockage, à cette clef USB. En l'espèce il s'agit de la lettre H (voir figure 1D). Il se produit donc un conflit illustré par l'incohérence des informations représentées aux figures 1C et ID, la lettre H ayant été affectée par l'utilisateur au lecteur réseau. 35 L'invention permet de détecter et résoudre ce conflit automatiquement. La figure 2 représente de façon schématique une clef USB 10 conforme à l'invention et une station hôte 20. Cette clef USB comporte notamment un connecteur USB pouvant être inséré dans un port USB 21 de la station hôte 20 et une 5 mémoire non volatile 12. Dans l'exemple décrit ici, la mémoire non volatile 12 comporte deux partitions 121, 122 définissant ainsi deux volumes logiques respectivement de types CDROM et REMOVABLE. La partition 121 de type CDROM est un support 10 d'enregistrement au sens de l'invention. Elle comporte un programme d'ordinateur PI de type � autorun � c'est-à-dire un programme pouvant être exécuté automatiquement lorsque la clef USB 10 est détectée par la station hôte 20. Le programme d'ordinateur Pl comporte des instructions pour 15 exécuter les étapes du procédé de détection de conflit conforme à l'invention, dont l'organigramme est représenté à la figure 3. Le programme d'ordinateur Pl comporte, dans cet exemple, des instructions pour déclencher l'exécution d'un programme d'ordinateur P2 applicatif mémorisé dans la partition 122 de type REMOVABLE. 20 En référence à la figure 3 nous allons maintenant décrire les principales étapes d'un procédé de détection et de résolution de conflit conforme à l'invention. Au cours d'une première étape El, le procédé conforme à l'invention recherche le premier nom de volume logique connecté à la 25 station hôte 20. Dans l'exemple de réalisation décrit ici, l'obtention d'un nom de volume logique se fait en appelant la fonction noyau FindNextVolume fournie par Microsoft. Puis, au cours d'une étape E2, en utilisant la fonction du noyau 30 QueryDosDevice fournie par Microsoft avec pour paramètre le nom de volume logique obtenu à l'étape El, on récupère le type typ_voll et un identifiant unique id_voll de ce volume. Dans le mode de réalisation de l'invention décrit ici, on s'intéresse uniquement aux types REMOVABLE et CDROM, les autres types 35 de volumes logiques (FIXED, FLOPPY, ne sont pas traités. Puis on recherche, dans une boucle constituée par les étapes E3 à E5, pour chaque lettre de lecteur de la station hôte 20, si l'identifiant unique id_voll du volume logique obtenu à l'étape E2 correspond à cette lettre. Pour cela, on utilise à l'étape E3, la fonction QueryDosDevice du mode utilisateur, avec une lettre en paramètre, pour obtenir l'identifiant de volume logique id_vol2 associé à cette lettre. Au cours de l'étape E4 on compare les identifiants id_voll et id_vol2 ainsi obtenus. Si ces identifiants sont égaux, il n'y a pas de conflit sur le volume logique concerné et on retourne à l'étape El déjà décrite pour traiter le nom de volume suivant. Le test E5 permet de vérifier que toutes les lettres de lecteur ont été traitées. Lorsque toutes les lettres ont été traitées (résultat du test E5 négatif) et qu'aucune lettre ne correspond au volume avec le même identifiant unique, alors il y a un conflit, celui-ci étant détecté à l'étape E6. Dans le mode de réalisation de l'invention décrit ici, on traite les volumes logiques de type REMOVABLE avant de traiter les volumes logiques de type CDROM. On notera que dans cet exemple, plusieurs types de volume sont identifiés, puisque la clef USB 10 comporte deux partitions 121, 122 de types différents (CDROM et REMOVABLE). Dans le mode de réalisation décrit ici, le procédé de détection et de résolution de conflit selon l'invention, comporte une étape E7 au cours de laquelle on vérifie si un périphérique d'un modèle prédéterminé est connecté à la station hôte 20. Pour cela, on recherche et on analyse l'identifiant donné par le constructeur à chacun des périphériques connectés à la station hôte 20. en effet d'usage que les composants électroniques, et notamment les clefs USB, possèdent des identifiants, conformément à la norme USB. Ces identifiants peuvent être constitués par des chaînes hexadécimales ou binaires par exemple. Un tel identifiant comporte généralement une partie commune identique pour tous les composants électroniques d'un même modèle et 35 une partie unique spécifique à chaque composant de ce modèle. Dans le cas des clefs USB, les identifiants comportent les champs suivants : - VEN : identifiant du vendeur PROD : identifiant du produit . SN : numéro de série et - une chaîne de description du produit. Dans l'exemple de réalisation décrit ici, les périphériques de modèle prédéterminés sont les périphériques pour lesquels : - l'identifiant du vendeur VEN est la chaine de caractères � SociétéX � ; et l'identifiant de produit PROD est la chaine de caractères � ProduitX �. Dans le mode de réalisation décrit ici, l'étape E7 est constituée par une boucle comportant les sous-étapes E71 à E74 pour traiter tous les périphériques d'un type recherché, REMOVABLE puis CDROM, connectés à la station hôte 20. Plus précisément, la sous-étape E71 permet d'obtenir un pointeur sur un périphérique du type choisi (REMOVABLE ou CDROM) en exécutant la fonction en mode noyau SetupDiGetClassDevs avec le type choisi passé en paramètre. Puis, au cours de la sous-étape E72, on utilise, toujours en mode noyau, la fonction SetupDiGetDevicelnstanceld pour obtenir l'identifiant id_dev2 du périphérique recherché en passant en paramètre le pointeur obtenu à la sous-étape précédente. Au cours d'un test E73 on vérifie que l'identifiant id_dev2 est un identifiant dont les champs VEN et PROD sont respectivement égaux aux chaines de caractères � SociétéX � et � ProduitX �. Si c'est le cas, le résultat du test E73 est positif et l'étape E7 se termine, un périphérique du modèle prédéterminé ayant été identifié. Sinon, on effectue les mêmes sous-étapes E71 à E73 pour les autres périphériques, tant que le résultat du test E74 est positif. Si tous les périphériques ont été traités (résultat du test E74 négatif) sans qu'un périphérique du modèle prédéterminé ait été identifié, on retourne à l'étape E déjà décrite pour rechercher le nom de volume logique suivant. On considère maintenant qu'un périphérique du modèle prédéterminé a été détecté. Dans l'exemple de réalisation décrit ici, le procédé de détection et de résolution de conflit selon l'invention cherche ensuite à déterminer si le périphérique de modèle prédéterminé est effectivement monté sur le volume logique en conflit identifié à l'étape E6. Pour cela, on obtient à partir de l'identifiant id_dev2 de ce périphérique, dans une étape générale E8, un numéro séquentiel num_dev2 attribué à ce périphérique par le système d'exploitation Windows XP. Dans le mode de réalisation décrit ici, cette étape générale E8 comporte deux sous-étapes E81 et E82. A la sous-étape E81, on dresse la liste des interfaces que présente le périphérique d'identifiant id_dev2. Pour cela on utilise la fonction SetupDiEnumInterface avec pour paramètre d'entrée l'identifiant id_dev2. Au cours de la même sous-étape E81, pour chaque interface trouvée, on récupère le chemin du périphérique (� Device Path � en anglais) à l'aide de la fonction SetupDiGetDevicelnterfaceDetail. Ce chemin de périphérique permet de récupérer un pointeur sur le périphérique physique par le biais de la fonction noyau CreateFile. Puis au cours de la sous-étape E82, on récupère le numéro séquentiel num_dev2 attribué au périphérique de modèle prédéterminé par le système d'exploitation Windows XP, à l'aide de la fonction DeviceloContml appelée avec pour paramètres : - le pointeur obtenu à la sous-étape précédente ; et - la constante 10CLSTORAGE_GET DEVICE_NUMBER. On notera que dans le cas du système Windows XP, on parcourt la liste de toutes les interfaces à la sous-étape E81, car pour certaines d'entres elles, le numéro séquentiel id_dev2 n'est pas retourné. Au cours d'une étape E9, on obtient le numéro séquentiel id_devl attribué par le système d'exploitation Windows XP au périphérique physique monté sur le volume logique en conflit. Pour cela on utilise la fonction du mode noyau CreateFile en lui passant en paramètre le nom du volume logique en conflit obtenu à l'étape El pour lequel un conflit a été détecté à l'étape E6. Comme décrit en référence à la sous-étape E81, cette fonction retourne un pointeur sur ce périphérique. Puis, on appelle, comme à la sous-étape E82, la fonction DeviceloControl avec ce pointeur et la constante 10CLSTORAGE_GELDEVICE_NUMBER pour paramètres. On obtient ainsi le numéro séquentiel num_devi périphérique physique monté sur le volume logique en conflit. Au cours d'une étape E10 on compare les numéros séquentiels num_devl et num_dev2. Si ces numéros sont identiques, le périphérique monté sur le volume logique en conflit est effectivement du modèle prédéterminé et le résultat du test E10 est positif. Dans le cas contraire, le résultat du test E10 est négatif et on retourne à l'étape El déjà décrite pour rechercher le nom de volume logique suivant. Lorsque le résultat du test E10 est positif, on résout le conflit 15 détecté à l'étape E6, au cours d'une étape générale El 1, en affectant une lettre disponible au volume logique en conflit Dans le mode de réalisation décrit ici, l'étape Ell comporte trois sous-étapes Elli à E113. La sous-étape E111 permet d'identifier à quelle lettre le nom de 20 volume en conflit aurait dû être associé en l'absence de conflit. Cette étape est nécessaire, les fonctions de programmation API de Windows imposant que l'on renseigne la lettre précédemment utilisée pour pouvoir démonter un lecteur réseau. Pour retrouver le nom de volume concerné, on consulte la base 25 de registres de Windows. Dans cette clef de la base de registres "HKEY_LOCALMACHINE \System \MountedDevices", on ouvre la donnée correspondant au nom du volume concerné pour obtenir sa valeur (ci-après � première valeur �). Ces opérations sont réalisées en utilisant, en mode utilisateur, les méthodes de gestion de la base de registre 30 RegOpenKeyEx et ReqQueryValueEx. Puis, toujours au cours de la sous-étape Ell on lit chacune des données contenues dans la base de registres au niveau de � System\MountedDevices � du type � DosDevice\X: � où X est une lettre de lecteur de la station hôte 20. Si le valeur de cette donnée correspond à la première valeur, on en déduit que le volume en conflit aurait dû être monté sur cette lettre s'il n'y avait pas eu de conflit Une fois que la lettre a été identifiée, on démonte le volume logique de l'endroit où il se trouve au cours de la sous-étape E112. Pour cela on utilise la fonction Windows DeleteVolumeMountPoint en mode utilisateur, avec pour paramètre la lettre à laquelle le volume aurait dû être affecté. Puis, au cours de la sous-étape E113, on monte le volume logique sur une lettre disponible choisie en dehors de la liste des lettres déjà attribuées, en utilisant, en mode utilisateur, la fonction SetVolumeMountPoint avec pour paramètres le nom de volume logique et cette lettre. Le conflit détecté à l'étape E6 est ainsi résolu. Dans ce mode de réalisation, le procédé selon l'invention retourne à l'étape El déjà décrite pour rechercher le nom de volume logique suivant. Dans le mode de réalisation décrit ci-dessus, la station hôte à l'architecture matérielle d'un ordinateur conventionnel. Elle comporte notamment un processeur, une mémoire morte de type ROM et une mémoire vive de type RAM. Ces différents moyens sont aptes à exécuter le programme d'ordinateur Pl pour mettre en oeuvre l'invention. En ce sens, ils constituent conjointement un dispositif de détection et de résolution de conflit au sens de l'invention susceptible de se produire lorsqu'on connecte le périphérique 10 à la station hôte 20. Ces moyens sont en effet aptes à: - obtenir au moins un nom de volume logique connecté à la station hôte 25 20 ; -obtenir, à partir du nom de ce volume logique, un identifiant unique id_voll de ce volume logique; - vérifier si l'identifiant unique (d_voll correspond à une lettre d'un lecteur de la station hôte 20 ; 30 détecter un conflit en cas d'échec de cette vérification ;et affecter une lettre disponible au volume logique afin de résoudre le conflit. REVENDICATIONS 1. Procédé de détection et de résolution d'un conflit susceptible de se produire lorsqu'on connecte un périphérique à une station hôte, ce procédé comportant : - une étape (El) d'obtention du nom d'au moins un volume logique 10 (nom_vol) connecté à ladite station hôte ; - une étape (E2) d'obtention, à partir dudit nom de volume logique (nom vol), et d'un identifiant unique (id_voll) dudit volume logique; - une étape (E3, E4) au cours de laquelle on vérifie si ledit identifiant unique (id_voll) dudit volume logique correspond à une lettre d'un 15 lecteur de ladite station hôte, un conflit étant détecté (E6) en cas d'échec de ladite étape (E3, E4) de vérification ; et, en cas de conflit : - une étape (E11) de résolution dudit conflit au cours de laquelle on affecte (E113) une lettre disponible audit volume logique. 20 2. Procédé de détection et de résolution de conflit selon la revendication 1, caractérisé en ce qu'on obtient également (E2), à partir dudit nom de volume logique (nom_vol), un type dudit (typ_voll) de ce volume logique, et en ce que ladite étape (E3, E4) de vérification est effectuée si ledit type (typ_voll) est un type prédéterminé (REMOVABLE, 25 CDROM). 3. Procédé de détection et de résolution de conflit selon la revendication 2, caractérisé en ce que, si on obtient (E2) des volumes logiques de plusieurs types (REMOVABLE, CDROM), on traite (E3, E4) 30 lesdits volumes logiques, dans un ordre prédéterminé en fonction de leur type (REMOVABLE, CDROM). 4. Procédé de détection et de résolution de conflit selon l'une quelconque des revendications 1 à 3, caractérisé en ce qu'il comporte en 35 outre une étape (E7) au cours de laquelle on vérifie si un périphérique d'un modèle prédéterminé est connecté à ladite station hôte. 5. Procédé de détection et de résolution de conflit selon la revendication 4, caractérisé en ce qu'il comporte en outre : - une étape d'obtention (E8), à partir d'un identifiant (id_dev2) dudit périphérique de modèle prédéterminé d'un numéro séquentiel (num_dev2) attribué à ce périphérique par le système d'exploitation de ladite station hôte ; - une étape d'obtention (E9) d'un numéro séquentiel (num_devl) attribué par ledit système d'exploitation, au périphérique physique monté sur ledit volume logique en conflit ; et une étape (ElO) de comparaison desdits numéros séquentiels (num_devi, num_dev2) pour déterminer si le périphérique monté sur ledit volume logique en conflit est un périphérique dudit modèle prédéterminé. 6. Procédé de détection et de résolution de conflit selon la revendication 5, caractérisé en ce que on obtient (E72) ledit identifiant (id_dev2) du périphérique de modèle prédéterminé par l'appel d'une fonction du noyau, et en ce que ladite étape (E9) d'obtention du numéro séquentiel (num_devl) attribué au périphérique physique monté sur le volume logique en conflit est mise en oeuvre par une fonction du niveau applicatif. 7. Procédé de détection et de résolution de conflit selon la revendication 5 ou 6, caractérisé en ce que ladite étape (E8) d'obtention de l'identifiant (id_dev2) dudit périphérique de modèle prédéterminé, comporte une sous-étape (E81) d'obtention de la liste des interfaces de ce périphérique. 8. Procédé de détection et de résolution de conflit selon l'une quelconque des revendications 1 à 7, caractérisé en ce que ladite étape (Eli) de résolution de conflit comporte: - une étape (E111) de recherche de la lettre qui aurait été affectée audit volume logique en l'absence de conflit ; une étape (E112) au cours de laquelle on démonte ledit volume logique de l'endroit où il se trouve ; et- une étape (E113) au cours de laquelle on monte ledit volume logique sur ladite lettre disponible. 9. Programme d'ordinateur comportant des instructions pour 5 l'exécution des étapes du procédé de détection et de résolution de conflit selon l'une quelconque des revendications 1 à 8 lorsque ledit programme est exécuté par un ordinateur. 10. Support d'enregistrement lisible par un ordinateur sur lequel 10 est enregistré un programme d'ordinateur comprenant des instructions pour l'exécution des étapes du procédé de détection et de résolution de conflit selon l'une quelconque des revendications 1 à 8. 11. Clef USB caractérisée en ce qu'elle constitue un support 15 d'enregistrement selon la revendication 10. 12. Clef USB selon la revendication 11, caractérisée en ce qu'elle comporte au moins deux volumes logiques et en ce que l'un de ces volumes logiques constitue un support d'enregistrement selon la 20 revendication 10. 13. Dispositif de détection et de résolution d'un conflit susceptible de se produire lorsqu'on connecte un périphérique à une station hôte comportant : 25 - des moyens d'obtention d'au moins un nom de volume logique (nom_vol) connecté à ladite station hôte ; - des moyens d'obtention, à partir dudit nom de volume logique (nom vol), et d'un identifiant unique (id_voll) dudit volume logique; - des moyens pour vérifier si ledit identifiant unique (id_voll) dudit 30 volume logique correspond à une lettre d'un lecteur de ladite station hôte ; - des moyens pour détecter un conflit en cas d'échec (E4) de ladite vérification (E3) ; et - des moyens pour affecter une lettre disponible audit volume logique afin 35 de résoudre ledit conflit.