Sur un DD de grosse capacité, j'ai plusieurs partitions. Mais comme
elles prennent de la place sur le bureau quand elles montent, j'ai
l'habitude de les démonter et de monter uniquement celle dont j'ai
ponctuellement besoin.à l'aide d'un alias.
Une façpn de procéder est par ex.
alias ssd="diskutil mountDisk /dev/disk7"
alias s1="diskutil mountDisk /dev/disk5"
alias s2="diskutil mountDisk /dev/disk4"
alias s3="diskutil mountDisk /dev/disk6"
Bref, cela me convient car la partion désirée monte rapidement.
Mais il y a un hic. C'est que pour une raison inexplicable, le nom des
partion change après une extinction du Mac.
s1 ne monte pas disk5 mais disk6 ou autre au hasard.
Seul ssd disk7 qui est le DD interne ne change pas (pour l'instant).
Bref, y a t-il une explication à cela ? Car, du coup; les alias ne
servent plus à rien.
--
A+
--
Romer
Si Sto 1 a été monté une fois puis démonté, il est conservé "en mémoire" (il est toujours dans "diskutil list") et "diskutil mount 'Sto 1'" devrait fonctionner, non ? Ce que je voulais dire est-il plus clair ?
À la réflexion, je crois que ce que je viens d'écrire est un peu débile... Si un volume est connecté et reconnu par le système, il est forcément présent dans "diskutil list". Mais je ne comprends toujours pas pourquoi "diskutil mount 'Sto 1'" est problématique alors que "diskutil umount 'Sto 1'" ne l'est pas... -- Michel Vauquois - <http://michelvauquois.fr> Nouveau : <http://art-doise-4.michelvauquois.free-h.fr> et <http://art-doise-5.michelvauquois.free-h.fr>
MV <mv@orange.invalid> wrote:
Si Sto 1 a été monté une fois puis démonté, il est conservé "en mémoire"
(il est toujours dans "diskutil list") et "diskutil mount 'Sto 1'"
devrait fonctionner, non ? Ce que je voulais dire est-il plus clair ?
À la réflexion, je crois que ce que je viens d'écrire est un peu
débile... Si un volume est connecté et reconnu par le système, il est
forcément présent dans "diskutil list".
Mais je ne comprends toujours pas pourquoi "diskutil mount 'Sto 1'" est
problématique alors que "diskutil umount 'Sto 1'" ne l'est pas...
--
Michel Vauquois - <http://michelvauquois.fr>
Nouveau : <http://art-doise-4.michelvauquois.free-h.fr>
et <http://art-doise-5.michelvauquois.free-h.fr>
Si Sto 1 a été monté une fois puis démonté, il est conservé "en mémoire" (il est toujours dans "diskutil list") et "diskutil mount 'Sto 1'" devrait fonctionner, non ? Ce que je voulais dire est-il plus clair ?
À la réflexion, je crois que ce que je viens d'écrire est un peu débile... Si un volume est connecté et reconnu par le système, il est forcément présent dans "diskutil list". Mais je ne comprends toujours pas pourquoi "diskutil mount 'Sto 1'" est problématique alors que "diskutil umount 'Sto 1'" ne l'est pas... -- Michel Vauquois - <http://michelvauquois.fr> Nouveau : <http://art-doise-4.michelvauquois.free-h.fr> et <http://art-doise-5.michelvauquois.free-h.fr>
mv
SbM a attiré mon attention en écrivant :
Comme il n'est pas monté diskutil mount ne peut pas y accéder (alors même qu'il apparaît via diskutil list, c'est bizarre je sais mais c'est comme ça. :))
Mais pourquoi ça marche sans souci chez moi ? diskutil mount EFI fait monter EFI diskutil mount 'Recovery HD' fait monter Recovery HD... Quelque chose m'échappe. Cordialement. -- Michel Vauquois - <http://michelvauquois.fr> Nouveau : <http://art-doise-4.michelvauquois.free-h.fr> et <http://art-doise-5.michelvauquois.free-h.fr>
SbM <someone@nowhere.com> a attiré mon attention en écrivant :
Comme il n'est pas monté diskutil mount ne peut pas y
accéder (alors même qu'il apparaît via diskutil list, c'est bizarre je
sais mais c'est comme ça. :))
Mais pourquoi ça marche sans souci chez moi ?
diskutil mount EFI
fait monter EFI
diskutil mount 'Recovery HD'
fait monter Recovery HD...
Quelque chose m'échappe.
Cordialement.
--
Michel Vauquois - <http://michelvauquois.fr>
Nouveau : <http://art-doise-4.michelvauquois.free-h.fr>
et <http://art-doise-5.michelvauquois.free-h.fr>
Comme il n'est pas monté diskutil mount ne peut pas y accéder (alors même qu'il apparaît via diskutil list, c'est bizarre je sais mais c'est comme ça. :))
Mais pourquoi ça marche sans souci chez moi ? diskutil mount EFI fait monter EFI diskutil mount 'Recovery HD' fait monter Recovery HD... Quelque chose m'échappe. Cordialement. -- Michel Vauquois - <http://michelvauquois.fr> Nouveau : <http://art-doise-4.michelvauquois.free-h.fr> et <http://art-doise-5.michelvauquois.free-h.fr>
mv
Bernd a attiré mon attention en écrivant :
unmount fonctionne mais pas mount - va omprendre !
Tu as essayé la solution proposée par SbM qui me semble très élégante et efficace ? Pour ta partition SSD (mais sans doute est-ce ta partition de démarrage et donc elle n'est pas démontable/montable) : diskutil mount `diskutil list | awk '/SSD/ {print $6}'` Pour Sto n : diskutil mount `diskutil list | awk '/Sto n/ {print $7}'` Cordialement. -- Michel Vauquois - <http://michelvauquois.fr> Nouveau : <http://art-doise-4.michelvauquois.free-h.fr> et <http://art-doise-5.michelvauquois.free-h.fr>
Bernd <romer@bernd.invalid> a attiré mon attention en écrivant :
unmount fonctionne mais pas mount - va omprendre !
Tu as essayé la solution proposée par SbM qui me semble très élégante et
efficace ?
Pour ta partition SSD (mais sans doute est-ce ta partition de démarrage
et donc elle n'est pas démontable/montable) :
diskutil mount `diskutil list | awk '/SSD/ {print $6}'`
Pour Sto n :
diskutil mount `diskutil list | awk '/Sto n/ {print $7}'`
Cordialement.
--
Michel Vauquois - <http://michelvauquois.fr>
Nouveau : <http://art-doise-4.michelvauquois.free-h.fr>
et <http://art-doise-5.michelvauquois.free-h.fr>
unmount fonctionne mais pas mount - va omprendre !
Tu as essayé la solution proposée par SbM qui me semble très élégante et efficace ? Pour ta partition SSD (mais sans doute est-ce ta partition de démarrage et donc elle n'est pas démontable/montable) : diskutil mount `diskutil list | awk '/SSD/ {print $6}'` Pour Sto n : diskutil mount `diskutil list | awk '/Sto n/ {print $7}'` Cordialement. -- Michel Vauquois - <http://michelvauquois.fr> Nouveau : <http://art-doise-4.michelvauquois.free-h.fr> et <http://art-doise-5.michelvauquois.free-h.fr>
romer
MV wrote:
Mais la commande à utiliser n'est pas "diskutil mountDisk /dev/Sto 1 " mais "diskutil mount 'Sto 1'"
Cela commence à devenir embrouillé dans ma tête =-) Mais bon, là bonne pioche... ça marche et même bien. Reste plus qu'à redémarrer. Mais je suis confiant - comme Sto 1 ne change jamais, l'alias devrait fonctionner. ------------------------------------- Redémmarage effectué : ça marche - comme, prévu. La commande de l'alias à écrire est donc : alias s1='diskutil mount "Sto 1"' # Monter Sto 1 Super, tout devient à présent opérationnel. Merci à vous tous de ces infos. En espérant ne pas à y revenir. Cela n'explique tj pas le changement de disk3s1 en disk6s1 au fil des redémarrage mais bon, cette nouvelle écriture de commande n'affecte plus l'alias. -- A+ -- Romer
MV <mv@orange.invalid> wrote:
Mais la commande à utiliser n'est pas
"diskutil mountDisk /dev/Sto 1 "
mais
"diskutil mount 'Sto 1'"
Cela commence à devenir embrouillé dans ma tête =-)
Mais bon, là bonne pioche...
ça marche et même bien.
Reste plus qu'à redémarrer. Mais je suis confiant - comme Sto 1 ne
change jamais, l'alias devrait fonctionner.
-------------------------------------
Redémmarage effectué :
ça marche - comme, prévu.
La commande de l'alias à écrire est donc :
alias s1='diskutil mount "Sto 1"' # Monter Sto 1
Super, tout devient à présent opérationnel.
Merci à vous tous de ces infos.
En espérant ne pas à y revenir.
Cela n'explique tj pas le changement de disk3s1 en disk6s1 au fil des
redémarrage mais bon, cette nouvelle écriture de commande n'affecte plus
l'alias.
Mais la commande à utiliser n'est pas "diskutil mountDisk /dev/Sto 1 " mais "diskutil mount 'Sto 1'"
Cela commence à devenir embrouillé dans ma tête =-) Mais bon, là bonne pioche... ça marche et même bien. Reste plus qu'à redémarrer. Mais je suis confiant - comme Sto 1 ne change jamais, l'alias devrait fonctionner. ------------------------------------- Redémmarage effectué : ça marche - comme, prévu. La commande de l'alias à écrire est donc : alias s1='diskutil mount "Sto 1"' # Monter Sto 1 Super, tout devient à présent opérationnel. Merci à vous tous de ces infos. En espérant ne pas à y revenir. Cela n'explique tj pas le changement de disk3s1 en disk6s1 au fil des redémarrage mais bon, cette nouvelle écriture de commande n'affecte plus l'alias. -- A+ -- Romer
romer
SbM wrote:
Si Sto 1 est déjà monté, pourquoi vouloir le re-monter ? Il doit y avoir un truc qui m'échappe dans la problématique exposée.
Je na sais plus si j'ai induit cette réponse ou pas. Mais, bref... Les 2 fonctionnent maintenant. Il me semble que c'est au niveau des guillemets que j'avais un peu foiré -- A+ -- Romer
SbM <someone@nowhere.com> wrote:
Si Sto 1 est déjà monté, pourquoi vouloir le re-monter ? Il doit y avoir
un truc qui m'échappe dans la problématique exposée.
Je na sais plus si j'ai induit cette réponse ou pas. Mais, bref...
Les 2 fonctionnent maintenant.
Il me semble que c'est au niveau des guillemets que j'avais un peu foiré
--
A+
--
Romer
Si Sto 1 est déjà monté, pourquoi vouloir le re-monter ? Il doit y avoir un truc qui m'échappe dans la problématique exposée.
Je na sais plus si j'ai induit cette réponse ou pas. Mais, bref... Les 2 fonctionnent maintenant. Il me semble que c'est au niveau des guillemets que j'avais un peu foiré -- A+ -- Romer
romer
MV wrote:
Pour ta partition SSD (mais sans doute est-ce ta partition de démarrage et donc elle n'est pas démontable/montable) :
Partition de démarrage du clone situé sur DD externe - donc elle monte.
diskutil mount `diskutil list | awk '/SSD/ {print $6}'` Pour Sto n : diskutil mount `diskutil list | awk '/Sto n/ {print $7}'`
Pour l'instant : diskutil mount `diskutil list | awk '/Sto 1/ {print $7}'` ne marche pas mais je ne désespère pas. Cela dit comme la solution simple ; diskutil mount "Sto 1" fonctionne bien, je crois que je vais en rester là. -- A+ -- Romer
MV <mv@orange.invalid> wrote:
Pour ta partition SSD (mais sans doute est-ce ta partition de démarrage
et donc elle n'est pas démontable/montable) :
Partition de démarrage du clone situé sur DD externe - donc elle monte.
diskutil mount `diskutil list | awk '/SSD/ {print $6}'`
Pour Sto n :
diskutil mount `diskutil list | awk '/Sto n/ {print $7}'`
Pour l'instant :
diskutil mount `diskutil list | awk '/Sto 1/ {print $7}'` ne marche pas
mais je ne désespère pas.
Cela dit comme la solution simple ;
diskutil mount "Sto 1"
fonctionne bien, je crois que je vais en rester là.
Pour ta partition SSD (mais sans doute est-ce ta partition de démarrage et donc elle n'est pas démontable/montable) :
Partition de démarrage du clone situé sur DD externe - donc elle monte.
diskutil mount `diskutil list | awk '/SSD/ {print $6}'` Pour Sto n : diskutil mount `diskutil list | awk '/Sto n/ {print $7}'`
Pour l'instant : diskutil mount `diskutil list | awk '/Sto 1/ {print $7}'` ne marche pas mais je ne désespère pas. Cela dit comme la solution simple ; diskutil mount "Sto 1" fonctionne bien, je crois que je vais en rester là. -- A+ -- Romer
someone
Bernd wrote:
MV wrote:
Pour ta partition SSD (mais sans doute est-ce ta partition de démarrage et donc elle n'est pas démontable/montable) :
Partition de démarrage du clone situé sur DD externe - donc elle monte.
diskutil mount `diskutil list | awk '/SSD/ {print $6}'` Pour Sto n :
diskutil mount `diskutil list | awk '/Sto n/ {print $7}'`
Pour l'instant : diskutil mount `diskutil list | awk '/Sto 1/ {print $7}'` ne marche pas mais je ne désespère pas. Cela dit comme la solution simple ; diskutil mount "Sto 1" fonctionne bien, je crois que je vais en rester là.
Ah bah oui ça fonctionne, au temps pour moi. Ils ont dû améliorer le truc depuis quelques versions d'OS X, je crois que mon utilisation de l'astuce awk remonte à Mavericks. Désolé pour le bruit, du coup. -- [SbM] "If the French were really intelligent, they'd speak English" (W. Sheed)
Bernd <romer@bernd.invalid> wrote:
MV <mv@orange.invalid> wrote:
> Pour ta partition SSD (mais sans doute est-ce ta partition de démarrage
> et donc elle n'est pas démontable/montable) :
Partition de démarrage du clone situé sur DD externe - donc elle monte.
> diskutil mount `diskutil list | awk '/SSD/ {print $6}'`
>
> Pour Sto n :
> diskutil mount `diskutil list | awk '/Sto n/ {print $7}'`
Pour l'instant :
diskutil mount `diskutil list | awk '/Sto 1/ {print $7}'` ne marche pas
mais je ne désespère pas.
Cela dit comme la solution simple ;
diskutil mount "Sto 1"
fonctionne bien, je crois que je vais en rester là.
Ah bah oui ça fonctionne, au temps pour moi. Ils ont dû améliorer le
truc depuis quelques versions d'OS X, je crois que mon utilisation de
l'astuce awk remonte à Mavericks. Désolé pour le bruit, du coup.
--
[SbM]
"If the French were really intelligent, they'd speak English" (W. Sheed)
Pour ta partition SSD (mais sans doute est-ce ta partition de démarrage et donc elle n'est pas démontable/montable) :
Partition de démarrage du clone situé sur DD externe - donc elle monte.
diskutil mount `diskutil list | awk '/SSD/ {print $6}'` Pour Sto n :
diskutil mount `diskutil list | awk '/Sto n/ {print $7}'`
Pour l'instant : diskutil mount `diskutil list | awk '/Sto 1/ {print $7}'` ne marche pas mais je ne désespère pas. Cela dit comme la solution simple ; diskutil mount "Sto 1" fonctionne bien, je crois que je vais en rester là.
Ah bah oui ça fonctionne, au temps pour moi. Ils ont dû améliorer le truc depuis quelques versions d'OS X, je crois que mon utilisation de l'astuce awk remonte à Mavericks. Désolé pour le bruit, du coup. -- [SbM] "If the French were really intelligent, they'd speak English" (W. Sheed)
pehache
Le 04/01/2018 à 11:55, MV a écrit :
pehache a attiré mon attention en écrivant :
Ah ouais... C'est quand même bigrement zarbi. Et donc, la remarque faite par pehache aujourd'hui est nulle et non avenue.
Du tout, car ce qu'on voit sur ces captures d'écran ne contredisent pas ce que j'ai écrit précédemment : ce qui a changé c'est le nom du /container/.
Pas seulement... Sur https://transfer.sh/ha61b/Monte_3.jpg, je vois que l'identifiant de la partition SSD est disk7s1 et sur https://transfer.sh/puF1L/Montes_1.jpg il est devenu disk6s1 et il ne s'agit pas là des containers mais bel et bien des volumes, non ?
De fait si le nom du container change, la référence du volume change aussi. Encore une fois : - disque physique /dev/disk3 (disk3 ne change pas) - partition APFS /dev/disk3sY (ce Y ne change pas non plus) nommée "Container diskZ" (ce Z peut changer) - disque virtuel /dev/diskZ contenant : - une seule partition /dev/diskZs1 nommée "SSD" (ou "Sto x", ou...) Depuis le début j'ai l'impression que Bernd mélange /dev/disk3sY et /dev/diskZ/s1, qui ne jouent pas du tout le même rôle.
Le 04/01/2018 à 11:55, MV a écrit :
pehache <pehache.7@gmail.com> a attiré mon attention en écrivant :
Ah ouais... C'est quand même bigrement zarbi.
Et donc, la remarque faite par pehache aujourd'hui est nulle et non
avenue.
Du tout, car ce qu'on voit sur ces captures d'écran ne contredisent pas
ce que j'ai écrit précédemment : ce qui a changé c'est le nom du
/container/.
Pas seulement...
Sur https://transfer.sh/ha61b/Monte_3.jpg, je vois que l'identifiant de
la partition SSD est disk7s1 et sur
https://transfer.sh/puF1L/Montes_1.jpg il est devenu disk6s1 et il ne
s'agit pas là des containers mais bel et bien des volumes, non ?
De fait si le nom du container change, la référence du volume change aussi.
Encore une fois :
- disque physique /dev/disk3 (disk3 ne change pas)
- partition APFS /dev/disk3sY (ce Y ne change pas non plus)
nommée "Container diskZ" (ce Z peut changer)
- disque virtuel /dev/diskZ contenant :
- une seule partition /dev/diskZs1
nommée "SSD" (ou "Sto x", ou...)
Depuis le début j'ai l'impression que Bernd mélange /dev/disk3sY et
/dev/diskZ/s1, qui ne jouent pas du tout le même rôle.
Ah ouais... C'est quand même bigrement zarbi. Et donc, la remarque faite par pehache aujourd'hui est nulle et non avenue.
Du tout, car ce qu'on voit sur ces captures d'écran ne contredisent pas ce que j'ai écrit précédemment : ce qui a changé c'est le nom du /container/.
Pas seulement... Sur https://transfer.sh/ha61b/Monte_3.jpg, je vois que l'identifiant de la partition SSD est disk7s1 et sur https://transfer.sh/puF1L/Montes_1.jpg il est devenu disk6s1 et il ne s'agit pas là des containers mais bel et bien des volumes, non ?
De fait si le nom du container change, la référence du volume change aussi. Encore une fois : - disque physique /dev/disk3 (disk3 ne change pas) - partition APFS /dev/disk3sY (ce Y ne change pas non plus) nommée "Container diskZ" (ce Z peut changer) - disque virtuel /dev/diskZ contenant : - une seule partition /dev/diskZs1 nommée "SSD" (ou "Sto x", ou...) Depuis le début j'ai l'impression que Bernd mélange /dev/disk3sY et /dev/diskZ/s1, qui ne jouent pas du tout le même rôle.
josephb
MV wrote:
Je ne suis pas certain que ça mette fin à mon étonnement : tu veux dire que chez toi aussi, les "identifiers" des volumes changent à chaque démarrage (à configuration identique bien sûr) ?
Je parle d'avec Lion, pas refait les tests depuis que je suis en El Cap : Je t'avais communiqué ce fait (19 juillet 2017) qui apparemment t'est passé au-dessus des oreilles ;-) Donc, je répète, à chaque démarrage non, mais de façon totalement imprévisible les identifiers pouvaient changer jusque et y compris pour le disque de boot ! et c'est bien ce qui m'avait "scotché" à l'époque, persuadé que j'étais que de façon immuable, disk0 serait le disque de démarrage, les autres (à configuration égale), héritant du même id dans le même ordre qu'au démarage précédent. Or ce n'est pas /toujours/ le cas. Les voies d'OS X sont parfois impénétrables… -- J. B.
MV <mv@orange.invalid> wrote:
Je ne suis pas certain que ça mette fin à mon étonnement : tu veux dire
que chez toi aussi, les "identifiers" des volumes changent à chaque
démarrage (à configuration identique bien sûr) ?
Je parle d'avec Lion, pas refait les tests depuis que je suis en El
Cap :
Je t'avais communiqué ce fait (19 juillet 2017) qui apparemment t'est
passé au-dessus des oreilles ;-)
Donc, je répète, à chaque démarrage non, mais de façon totalement
imprévisible les identifiers pouvaient changer jusque et y compris pour
le disque de boot !
et c'est bien ce qui m'avait "scotché" à l'époque, persuadé que j'étais
que de façon immuable, disk0 serait le disque de démarrage, les autres
(à configuration égale), héritant du même id dans le même ordre qu'au
démarage précédent.
Or ce n'est pas /toujours/ le cas.
Les voies d'OS X sont parfois impénétrables…
--
J. B.
Je ne suis pas certain que ça mette fin à mon étonnement : tu veux dire que chez toi aussi, les "identifiers" des volumes changent à chaque démarrage (à configuration identique bien sûr) ?
Je parle d'avec Lion, pas refait les tests depuis que je suis en El Cap : Je t'avais communiqué ce fait (19 juillet 2017) qui apparemment t'est passé au-dessus des oreilles ;-) Donc, je répète, à chaque démarrage non, mais de façon totalement imprévisible les identifiers pouvaient changer jusque et y compris pour le disque de boot ! et c'est bien ce qui m'avait "scotché" à l'époque, persuadé que j'étais que de façon immuable, disk0 serait le disque de démarrage, les autres (à configuration égale), héritant du même id dans le même ordre qu'au démarage précédent. Or ce n'est pas /toujours/ le cas. Les voies d'OS X sont parfois impénétrables… -- J. B.
josephb
Bernd wrote:
J'ignorais que cette difficulté de montage par scrip shell était connue même avant high sierra. Une recherche sur le web il y a qq jours n'avait rien donné. Donc je m'était tourné vers le forum.
Au sein des seins d'Apple et quelques gourous es-OS X, ce phénomène d'attribution "aléatoire" d'id à configuration identique, d'un démarrage à l'autre, est forcément connu. Par quel mécanisme cela peut arriver, je n'en sais rien, mais c'est un fait qu'on est au moins deux autres à l'avoir rencontré. Mais aussi parce que dans ton cas, comme dans celui qui concernait mon programme, on est dans une demande très pointue que les utilisateurs n'ont en principe jamais l'occaion de rencontrer (ils sont censés passer par le Finder ou Utilitaire de Disque, pas par des commandes shell). Cela dit, on avait trouvé une solution pour palier ces cas de id aléatoire, mais qui obligeait à invoquer deux commandes Shell et comparer les résultats afin d'associer avec certitude les volumes par leur nom (pour l'interface utilisateur) et leur Id (pour les commandes mount et unmount). -- J. B.
Bernd <romer@bernd.invalid> wrote:
J'ignorais que cette difficulté de montage par scrip shell était connue
même avant high sierra.
Une recherche sur le web il y a qq jours n'avait rien donné. Donc je
m'était tourné vers le forum.
Au sein des seins d'Apple et quelques gourous es-OS X, ce phénomène
d'attribution "aléatoire" d'id à configuration identique, d'un démarrage
à l'autre, est forcément connu. Par quel mécanisme cela peut arriver, je
n'en sais rien, mais c'est un fait qu'on est au moins deux autres à
l'avoir rencontré.
Mais aussi parce que dans ton cas, comme dans celui qui concernait mon
programme, on est dans une demande très pointue que les utilisateurs
n'ont en principe jamais l'occaion de rencontrer (ils sont censés passer
par le Finder ou Utilitaire de Disque, pas par des commandes shell).
Cela dit, on avait trouvé une solution pour palier ces cas de id
aléatoire, mais qui obligeait à invoquer deux commandes Shell et
comparer les résultats afin d'associer avec certitude les volumes par
leur nom (pour l'interface utilisateur) et leur Id (pour les commandes
mount et unmount).
--
J. B.
J'ignorais que cette difficulté de montage par scrip shell était connue même avant high sierra. Une recherche sur le web il y a qq jours n'avait rien donné. Donc je m'était tourné vers le forum.
Au sein des seins d'Apple et quelques gourous es-OS X, ce phénomène d'attribution "aléatoire" d'id à configuration identique, d'un démarrage à l'autre, est forcément connu. Par quel mécanisme cela peut arriver, je n'en sais rien, mais c'est un fait qu'on est au moins deux autres à l'avoir rencontré. Mais aussi parce que dans ton cas, comme dans celui qui concernait mon programme, on est dans une demande très pointue que les utilisateurs n'ont en principe jamais l'occaion de rencontrer (ils sont censés passer par le Finder ou Utilitaire de Disque, pas par des commandes shell). Cela dit, on avait trouvé une solution pour palier ces cas de id aléatoire, mais qui obligeait à invoquer deux commandes Shell et comparer les résultats afin d'associer avec certitude les volumes par leur nom (pour l'interface utilisateur) et leur Id (pour les commandes mount et unmount). -- J. B.
