Je débarque sous gnome, et je rencontre un gros problème :
J'ai une partition fixe (/dev/sda1) qui est formatée en NTFS, que je veux monter dans /media/winxp
Mon but : avoir les droits en lecture/écriture dessus, sans être root et sans devoir taper de mot de passe supplémentaire
Contraintes : je ne veux pas que la partition soit montée automatiquement au démarrage, et je veux avec ce même utilisateur, avoir le droit de umount et mount cette partition
Du coup, j'ai procédé comme j'ai toujours fait : je me suis mis dans le groupe fuse, disk, j'ai ajouté une entrée au fstab (avec user,noauto notamment), j'ai chmod comme il faut l'exécutable ntfs-3g.
Au final, tout marche bien, quand je fais :
mount /media/winxp
il n'y a aucun problème
de même, si je tape :
gnome-mount -bd /dev/sda1
ça marche très bien.
Le hic, c'est que j'aimerais que dans nautilus, je puisse monter cette partition comme cela devrait être possible avec un clic droit, ou un double clic.
Or, quand j'essaie depuis nautilus, avec le même utilisateur, il me dit : accès à /dev/sda1 refusé
et ça, je ne comprends vraiment pas pourquoi... :
quelques infos :
-- ls -al /dev/sda1
brw-rw---- 1 root disk 8, 1 déc. 21 21:58 /dev/sda1
-- point de montage :
drwxrwxr-x 2 root fuse 4096 déc. 21 15:47 winxp
-- mon entrée dans fstab :
/dev/sda1 /media/winxp ntfs-3g umask=002,rw,user,noauto,locale=fr_FR.UTF-8 0 0
-- j'ai essayé un naïf "sudo chmod 777 /dev/sda1", et quand j'essaie de monter ma partition depuis nautilus, il me dit : "failed to chdir to mountpoint, permission non accordée"
-- je fais donc : "sudo chmod 777 /dev/sda1 && chmod 777 /media/winxp"
et là, ça marche. par contre, cela réinitialise les droits initiaux de /dev/sda1 (le 777 s'en va), donc si je démonte, je ne peux plus remonter sans chmodder... !
bref, le point crucial est que tout marche en ligne de commande : pour résoudre mon problème il me faudrait comprendre comment Nautilus essaie de monter ma partition... ! j'ai l'impression qu'il fait son job sous un autre utilisateur au vu des messages d'erreur... !
Le 22 Dec 2009 11:41:10 GMT Nicolas George <nicolas$ a écrit :
Yliur wrote in message : > Et modifier les droits de fichiers virtuels
Temporaires, pas virtuels.
Je voulais dire que ce ne sont pas de vrais fichiers au sens où ils ne sont stockés nulle part. Ce sont des entrées <suppr>virtuelles</suppr> pour rire dans l'arborescence des fichiers.
C'est mal de dire "virtuels" ? On peut confondre avec autre chose ?
> réinitialisés à > chaque > démarrage par le noyau
Par udev, pas par le noyau.
Pardon. Mmmm... Une question en passant : comment udev fait pour créer des fichiers qui n'existent pas ? J'imagine qu'il doit obligatoirement demander un service au noyau, non ? Tu disais qu'ils étaient "temporaires" plutôt que "virtuels". Est-ce que ce sont des noeuds réellement ajoutés au système de fichiers mais qui renvoient vers udev (ou je ne sais trop qui) quand on demande à les lire ?
Le 22 Dec 2009 11:41:10 GMT
Nicolas George <nicolas$george@salle-s.org> a écrit :
Yliur wrote in message <20091222123606.3ebed444@alcheringa>:
> Et modifier les droits de fichiers virtuels
Temporaires, pas virtuels.
Je voulais dire que ce ne sont pas de vrais fichiers au sens où ils ne
sont stockés nulle part. Ce sont des entrées
<suppr>virtuelles</suppr> pour rire dans l'arborescence des fichiers.
C'est mal de dire "virtuels" ? On peut confondre avec autre chose ?
> réinitialisés à
> chaque
> démarrage par le noyau
Par udev, pas par le noyau.
Pardon.
Mmmm... Une question en passant : comment udev fait pour créer des
fichiers qui n'existent pas ? J'imagine qu'il doit obligatoirement
demander un service au noyau, non ? Tu disais qu'ils étaient
"temporaires" plutôt que "virtuels". Est-ce que ce sont des noeuds
réellement ajoutés au système de fichiers mais qui renvoient vers
udev (ou je ne sais trop qui) quand on demande à les lire ?
Le 22 Dec 2009 11:41:10 GMT Nicolas George <nicolas$ a écrit :
Yliur wrote in message : > Et modifier les droits de fichiers virtuels
Temporaires, pas virtuels.
Je voulais dire que ce ne sont pas de vrais fichiers au sens où ils ne sont stockés nulle part. Ce sont des entrées <suppr>virtuelles</suppr> pour rire dans l'arborescence des fichiers.
C'est mal de dire "virtuels" ? On peut confondre avec autre chose ?
> réinitialisés à > chaque > démarrage par le noyau
Par udev, pas par le noyau.
Pardon. Mmmm... Une question en passant : comment udev fait pour créer des fichiers qui n'existent pas ? J'imagine qu'il doit obligatoirement demander un service au noyau, non ? Tu disais qu'ils étaient "temporaires" plutôt que "virtuels". Est-ce que ce sont des noeuds réellement ajoutés au système de fichiers mais qui renvoient vers udev (ou je ne sais trop qui) quand on demande à les lire ?
Yliur
Le 22 Dec 2009 11:36:52 GMT Nicolas George <nicolas$ a écrit :
singletonne wrote in message : > En fait, de ce que j'en ai compris, si je ne suis pas dans le groupe > "disk" alors l'accès à /dev/sda1 m'est refusé
Oui.
> et je ne peux jamais > monter > la partition
Aucun rapport. À moins d'utiliser FUSE, ce qui n'a pas l'air d'être le cas, le droit de monter la partition est indépendant du droit de lire son block device.
> par contre cela requiert un > redémarrage de l'ordinateur pour que les changements, à savoir "sudo > deluser moi disk" prennent effet (pourquoi ?))
Non, juste une réouverture de la session, puisque l'appartenance aux groupes est appliquée lors de la création du processus de login de l'utilisateur.
> Je comprends tout à fait que cela ne soit pas du tout la bonne > manière de faire, puisque du coup, j'acquiert tous les droits sur > les autres partitions, ce dont je n'ai évidemment pas besoin...
Bien vu.
> Après, j'imagine qu'on pourrait étendre les droits de /dev/sda1 > pour tous les utilisateurs, peut-être que cela serait plus > approprié ?
Si vraiment tu tiens à avoir les droits sur hda1, tu configures udev pour la mettre dans ton groupe utilisateur ou un groupe dédié. Mais ce n'est pas nécessaire.
> Et sinon, le "pourquoi", et bien c'est simplement pour apprendre, > quitte à revenir à un montage protégé par mot de passe, je suis > curieux et j'aimerais comprendre ce qui bloque dans mon cas !
Ce que tu n'as toujours pas expliqué, c'est pourquoi tu veux un montage manuel pour une partition fixe.
Tsss... Après on va encore s'entendre dire "quand les linuxiens ne peuvent pas arranger un problème, ils disent que ça ne sert à rien" ;) .
C'est vrai que si sa partition peut être montée automatiquement et que ça permet de contourner le problème c'est une bonne solution pratique, mais c'est quand même bien de savoir pourquoi pour avancer dans sa compréhension du bidule... Moi aussi je trouve ça bizarre que sa partition ne se monte pas manuellement, en principe c'est assez simple à faire (enfin dans Nautilus je ne sais pas).
Le 22 Dec 2009 11:36:52 GMT
Nicolas George <nicolas$george@salle-s.org> a écrit :
singletonne wrote in message <CvSdnRSSSdsdMa3WRVn_vwA@giganews.com>:
> En fait, de ce que j'en ai compris, si je ne suis pas dans le groupe
> "disk" alors l'accès à /dev/sda1 m'est refusé
Oui.
> et je ne peux jamais
> monter
> la partition
Aucun rapport. À moins d'utiliser FUSE, ce qui n'a pas l'air d'être
le cas, le droit de monter la partition est indépendant du droit de
lire son block device.
> par contre cela requiert un
> redémarrage de l'ordinateur pour que les changements, à savoir "sudo
> deluser moi disk" prennent effet (pourquoi ?))
Non, juste une réouverture de la session, puisque l'appartenance aux
groupes est appliquée lors de la création du processus de login de
l'utilisateur.
> Je comprends tout à fait que cela ne soit pas du tout la bonne
> manière de faire, puisque du coup, j'acquiert tous les droits sur
> les autres partitions, ce dont je n'ai évidemment pas besoin...
Bien vu.
> Après, j'imagine qu'on pourrait étendre les droits de /dev/sda1
> pour tous les utilisateurs, peut-être que cela serait plus
> approprié ?
Si vraiment tu tiens à avoir les droits sur hda1, tu configures udev
pour la mettre dans ton groupe utilisateur ou un groupe dédié. Mais
ce n'est pas nécessaire.
> Et sinon, le "pourquoi", et bien c'est simplement pour apprendre,
> quitte à revenir à un montage protégé par mot de passe, je suis
> curieux et j'aimerais comprendre ce qui bloque dans mon cas !
Ce que tu n'as toujours pas expliqué, c'est pourquoi tu veux un
montage manuel pour une partition fixe.
Tsss... Après on va encore s'entendre dire "quand les linuxiens ne
peuvent pas arranger un problème, ils disent que ça ne sert à
rien" ;) .
C'est vrai que si sa partition peut être montée automatiquement et que
ça permet de contourner le problème c'est une bonne solution
pratique, mais c'est quand même bien de savoir pourquoi pour avancer
dans sa compréhension du bidule... Moi aussi je trouve ça bizarre que
sa partition ne se monte pas manuellement, en principe c'est assez
simple à faire (enfin dans Nautilus je ne sais pas).
Le 22 Dec 2009 11:36:52 GMT Nicolas George <nicolas$ a écrit :
singletonne wrote in message : > En fait, de ce que j'en ai compris, si je ne suis pas dans le groupe > "disk" alors l'accès à /dev/sda1 m'est refusé
Oui.
> et je ne peux jamais > monter > la partition
Aucun rapport. À moins d'utiliser FUSE, ce qui n'a pas l'air d'être le cas, le droit de monter la partition est indépendant du droit de lire son block device.
> par contre cela requiert un > redémarrage de l'ordinateur pour que les changements, à savoir "sudo > deluser moi disk" prennent effet (pourquoi ?))
Non, juste une réouverture de la session, puisque l'appartenance aux groupes est appliquée lors de la création du processus de login de l'utilisateur.
> Je comprends tout à fait que cela ne soit pas du tout la bonne > manière de faire, puisque du coup, j'acquiert tous les droits sur > les autres partitions, ce dont je n'ai évidemment pas besoin...
Bien vu.
> Après, j'imagine qu'on pourrait étendre les droits de /dev/sda1 > pour tous les utilisateurs, peut-être que cela serait plus > approprié ?
Si vraiment tu tiens à avoir les droits sur hda1, tu configures udev pour la mettre dans ton groupe utilisateur ou un groupe dédié. Mais ce n'est pas nécessaire.
> Et sinon, le "pourquoi", et bien c'est simplement pour apprendre, > quitte à revenir à un montage protégé par mot de passe, je suis > curieux et j'aimerais comprendre ce qui bloque dans mon cas !
Ce que tu n'as toujours pas expliqué, c'est pourquoi tu veux un montage manuel pour une partition fixe.
Tsss... Après on va encore s'entendre dire "quand les linuxiens ne peuvent pas arranger un problème, ils disent que ça ne sert à rien" ;) .
C'est vrai que si sa partition peut être montée automatiquement et que ça permet de contourner le problème c'est une bonne solution pratique, mais c'est quand même bien de savoir pourquoi pour avancer dans sa compréhension du bidule... Moi aussi je trouve ça bizarre que sa partition ne se monte pas manuellement, en principe c'est assez simple à faire (enfin dans Nautilus je ne sais pas).
Yliur
Le Tue, 22 Dec 2009 05:24:48 -0600 singletonne a écrit :
Nicolas George a écrit le 22/12/2009 à 11h46 : > singletonne wrote in message : >> Je me suis mis dans le groupe "disk" parce que /dev/sda1 est chown >> en >> root:disk automatiquement au démarrage ! >> > > Et alors ? > >> Pour l'autre question, c'est recommandé par la doc de ntfs-3g de >> faire un >> chmod 4755 sur /usr/bin/ntfs-3g pour pouvoir l'utiliser en mode >> utilisateur. >> > > Et pourquoi vouloir l'utiliser « en mode utilisateur » > (ce qui, soit dit en > passant, est du charabia). En fait, de ce que j'en ai compris, si je ne suis pas dans le groupe "disk" alors l'accès à /dev/sda1 m'est refusé et je ne peux jamais monter la partition (test fait à l'instant; par contre cela requiert un redémarrage de l'ordinateur pour que les changements, à savoir "sudo deluser moi disk" prennent effet (pourquoi ?)) Je comprends tout à fait que cela ne soit pas du tout la bonne manière de faire, puisque du coup, j'acquiert tous les droits sur les autres partitions, ce dont je n'ai évidemment pas besoin... Après, j'imagine qu'on pourrait étendre les droits de /dev/sda1 pour tous les utilisateurs, peut-être que cela serait plus approprié ?
Et sinon, le "pourquoi", et bien c'est simplement pour apprendre, quitte à revenir à un montage protégé par mot de passe, je suis curieux et j'aimerais comprendre ce qui bloque dans mon cas ! Je reviens juste sous linux après presque 10 ans sans l'utiliser, et apparemment j'ai perdu pas mal, mais j'aime toujours aller au fond des choses :-)
Et, merci de votre patience !
Juste une question : quand tu dis que ça amrche à la main, est-ce que ça marche en faisant simplement mount /media/winxp, avec un simple utilisateur et sans modifier aucun droit (avec bien sûr l'entrée dans fstab) ?
Le Tue, 22 Dec 2009 05:24:48 -0600
singletonne <singletonne@domain-xyz.in> a écrit :
Nicolas George a écrit le 22/12/2009 à 11h46 :
> singletonne wrote in message :
>> Je me suis mis dans le groupe "disk" parce que /dev/sda1 est chown
>> en
>> root:disk automatiquement au démarrage !
>>
>
> Et alors ?
>
>> Pour l'autre question, c'est recommandé par la doc de ntfs-3g de
>> faire un
>> chmod 4755 sur /usr/bin/ntfs-3g pour pouvoir l'utiliser en mode
>> utilisateur.
>>
>
> Et pourquoi vouloir l'utiliser « en mode utilisateur »
> (ce qui, soit dit en
> passant, est du charabia).
En fait, de ce que j'en ai compris, si je ne suis pas dans le groupe
"disk" alors l'accès à /dev/sda1 m'est refusé et je ne peux jamais
monter la partition (test fait à l'instant; par contre cela requiert
un redémarrage de l'ordinateur pour que les changements, à savoir
"sudo deluser moi disk" prennent effet (pourquoi ?))
Je comprends tout à fait que cela ne soit pas du tout la bonne
manière de faire, puisque du coup, j'acquiert tous les droits sur les
autres partitions, ce dont je n'ai évidemment pas besoin...
Après, j'imagine qu'on pourrait étendre les droits de /dev/sda1 pour
tous les utilisateurs, peut-être que cela serait plus approprié ?
Et sinon, le "pourquoi", et bien c'est simplement pour apprendre,
quitte à revenir à un montage protégé par mot de passe, je suis
curieux et j'aimerais comprendre ce qui bloque dans mon cas !
Je reviens juste sous linux après presque 10 ans sans l'utiliser, et
apparemment j'ai perdu pas mal, mais j'aime toujours aller au fond
des choses :-)
Et, merci de votre patience !
Juste une question : quand tu dis que ça amrche à la main, est-ce que
ça marche en faisant simplement mount /media/winxp, avec un simple
utilisateur et sans modifier aucun droit (avec bien sûr l'entrée
dans fstab) ?
Le Tue, 22 Dec 2009 05:24:48 -0600 singletonne a écrit :
Nicolas George a écrit le 22/12/2009 à 11h46 : > singletonne wrote in message : >> Je me suis mis dans le groupe "disk" parce que /dev/sda1 est chown >> en >> root:disk automatiquement au démarrage ! >> > > Et alors ? > >> Pour l'autre question, c'est recommandé par la doc de ntfs-3g de >> faire un >> chmod 4755 sur /usr/bin/ntfs-3g pour pouvoir l'utiliser en mode >> utilisateur. >> > > Et pourquoi vouloir l'utiliser « en mode utilisateur » > (ce qui, soit dit en > passant, est du charabia). En fait, de ce que j'en ai compris, si je ne suis pas dans le groupe "disk" alors l'accès à /dev/sda1 m'est refusé et je ne peux jamais monter la partition (test fait à l'instant; par contre cela requiert un redémarrage de l'ordinateur pour que les changements, à savoir "sudo deluser moi disk" prennent effet (pourquoi ?)) Je comprends tout à fait que cela ne soit pas du tout la bonne manière de faire, puisque du coup, j'acquiert tous les droits sur les autres partitions, ce dont je n'ai évidemment pas besoin... Après, j'imagine qu'on pourrait étendre les droits de /dev/sda1 pour tous les utilisateurs, peut-être que cela serait plus approprié ?
Et sinon, le "pourquoi", et bien c'est simplement pour apprendre, quitte à revenir à un montage protégé par mot de passe, je suis curieux et j'aimerais comprendre ce qui bloque dans mon cas ! Je reviens juste sous linux après presque 10 ans sans l'utiliser, et apparemment j'ai perdu pas mal, mais j'aime toujours aller au fond des choses :-)
Et, merci de votre patience !
Juste une question : quand tu dis que ça amrche à la main, est-ce que ça marche en faisant simplement mount /media/winxp, avec un simple utilisateur et sans modifier aucun droit (avec bien sûr l'entrée dans fstab) ?
Nicolas George
Yliur wrote in message :
Je voulais dire que ce ne sont pas de vrais fichiers au sens où ils ne sont stockés nulle part. Ce sont des entrées <suppr>virtuelles</suppr> pour rire dans l'arborescence des fichiers.
Si, ils sont bien stockés quelque part : ils sont stockés dans le filesystem tmpfs monté dans /dev. Ce filesystem réside en RAM et pas sur un block device, mais c'est un filesystem à part entière. Tu peux y mettre les fichiers que tu veux, y compris des fichiers réguliers.
C'est mal de dire "virtuels" ? On peut confondre avec autre chose ?
Oui. Les entrées dans procfs et sysfs sont elles plus exactement virtuelles, il n'y a pas de stockage, les listes et les contenus sont générés à la volée à partir des structures de données du noyau.
C'est aussi vrai pour devfs des noyaux 2.4, même si c'était un peu intermédiaire, puisque les noms et les droits étaient stockés à part entière, de même d'ailleurs que des liens symboliques et des sockets.
Mmmm... Une question en passant : comment udev fait pour créer des fichiers qui n'existent pas ?
Avec mknod, comme tout le monde.
J'imagine qu'il doit obligatoirement demander un service au noyau, non ?
Oui, mais ce n'est pas le noyau qui prend l'initiative.
Tu disais qu'ils étaient "temporaires" plutôt que "virtuels". Est-ce que ce sont des noeuds réellement ajoutés au système de fichiers
Oui, mais le système de fichiers tmpfs monté dans /dev.
mais qui renvoient vers udev (ou je ne sais trop qui) quand on demande à les lire ?
Non, ce sont des fichiers de device, ils renvoient au noyau. udev est là uniquement pour les créer et les effacer.
Yliur wrote in message <20091222124923.49b9fa1f@alcheringa>:
Je voulais dire que ce ne sont pas de vrais fichiers au sens où ils ne
sont stockés nulle part. Ce sont des entrées
<suppr>virtuelles</suppr> pour rire dans l'arborescence des fichiers.
Si, ils sont bien stockés quelque part : ils sont stockés dans le filesystem
tmpfs monté dans /dev. Ce filesystem réside en RAM et pas sur un block
device, mais c'est un filesystem à part entière. Tu peux y mettre les
fichiers que tu veux, y compris des fichiers réguliers.
C'est mal de dire "virtuels" ? On peut confondre avec autre chose ?
Oui. Les entrées dans procfs et sysfs sont elles plus exactement virtuelles,
il n'y a pas de stockage, les listes et les contenus sont générés à la volée
à partir des structures de données du noyau.
C'est aussi vrai pour devfs des noyaux 2.4, même si c'était un peu
intermédiaire, puisque les noms et les droits étaient stockés à part
entière, de même d'ailleurs que des liens symboliques et des sockets.
Mmmm... Une question en passant : comment udev fait pour créer des
fichiers qui n'existent pas ?
Avec mknod, comme tout le monde.
J'imagine qu'il doit obligatoirement
demander un service au noyau, non ?
Oui, mais ce n'est pas le noyau qui prend l'initiative.
Tu disais qu'ils étaient
"temporaires" plutôt que "virtuels". Est-ce que ce sont des noeuds
réellement ajoutés au système de fichiers
Oui, mais le système de fichiers tmpfs monté dans /dev.
mais qui renvoient vers
udev (ou je ne sais trop qui) quand on demande à les lire ?
Non, ce sont des fichiers de device, ils renvoient au noyau. udev est là
uniquement pour les créer et les effacer.
Je voulais dire que ce ne sont pas de vrais fichiers au sens où ils ne sont stockés nulle part. Ce sont des entrées <suppr>virtuelles</suppr> pour rire dans l'arborescence des fichiers.
Si, ils sont bien stockés quelque part : ils sont stockés dans le filesystem tmpfs monté dans /dev. Ce filesystem réside en RAM et pas sur un block device, mais c'est un filesystem à part entière. Tu peux y mettre les fichiers que tu veux, y compris des fichiers réguliers.
C'est mal de dire "virtuels" ? On peut confondre avec autre chose ?
Oui. Les entrées dans procfs et sysfs sont elles plus exactement virtuelles, il n'y a pas de stockage, les listes et les contenus sont générés à la volée à partir des structures de données du noyau.
C'est aussi vrai pour devfs des noyaux 2.4, même si c'était un peu intermédiaire, puisque les noms et les droits étaient stockés à part entière, de même d'ailleurs que des liens symboliques et des sockets.
Mmmm... Une question en passant : comment udev fait pour créer des fichiers qui n'existent pas ?
Avec mknod, comme tout le monde.
J'imagine qu'il doit obligatoirement demander un service au noyau, non ?
Oui, mais ce n'est pas le noyau qui prend l'initiative.
Tu disais qu'ils étaient "temporaires" plutôt que "virtuels". Est-ce que ce sont des noeuds réellement ajoutés au système de fichiers
Oui, mais le système de fichiers tmpfs monté dans /dev.
mais qui renvoient vers udev (ou je ne sais trop qui) quand on demande à les lire ?
Non, ce sont des fichiers de device, ils renvoient au noyau. udev est là uniquement pour les créer et les effacer.
Nicolas George
Yliur wrote in message :
C'est vrai que si sa partition peut être montée automatiquement et que ça permet de contourner le problème c'est une bonne solution pratique, mais c'est quand même bien de savoir pourquoi pour avancer dans sa compréhension du bidule...
La compréhension du bidule, ça commence par savoir discerner les bons objectifs des mauvais.
Yliur wrote in message <20091222125252.5150952b@alcheringa>:
C'est vrai que si sa partition peut être montée automatiquement et que
ça permet de contourner le problème c'est une bonne solution
pratique, mais c'est quand même bien de savoir pourquoi pour avancer
dans sa compréhension du bidule...
La compréhension du bidule, ça commence par savoir discerner les bons
objectifs des mauvais.
C'est vrai que si sa partition peut être montée automatiquement et que ça permet de contourner le problème c'est une bonne solution pratique, mais c'est quand même bien de savoir pourquoi pour avancer dans sa compréhension du bidule...
La compréhension du bidule, ça commence par savoir discerner les bons objectifs des mauvais.
Yliur
Le 22 Dec 2009 12:05:37 GMT Nicolas George <nicolas$ a écrit :
Yliur wrote in message : > Je voulais dire que ce ne sont pas de vrais fichiers au sens où ils > ne sont stockés nulle part. Ce sont des entrées > <suppr>virtuelles</suppr> pour rire dans l'arborescence des > fichiers.
Si, ils sont bien stockés quelque part : ils sont stockés dans le filesystem tmpfs monté dans /dev. Ce filesystem réside en RAM et pas sur un block device, mais c'est un filesystem à part entière. Tu peux y mettre les fichiers que tu veux, y compris des fichiers réguliers.
> C'est mal de dire "virtuels" ? On peut confondre avec autre chose ?
Oui. Les entrées dans procfs et sysfs sont elles plus exactement virtuelles, il n'y a pas de stockage, les listes et les contenus sont générés à la volée à partir des structures de données du no yau.
C'est aussi vrai pour devfs des noyaux 2.4, même si c'était un peu intermédiaire, puisque les noms et les droits étaient stockés à p art entière, de même d'ailleurs que des liens symboliques et des sockets.
> Mmmm... Une question en passant : comment udev fait pour créer des > fichiers qui n'existent pas ?
Avec mknod, comme tout le monde.
> J'imagine qu'il doit > obligatoirement > demander un service au noyau, non ?
Oui, mais ce n'est pas le noyau qui prend l'initiative.
> Tu disais qu'ils étaient > "temporaires" plutôt que "virtuels". Est-ce que ce sont des noeuds > réellement ajoutés au système de fichiers
Oui, mais le système de fichiers tmpfs monté dans /dev.
> mais qui renvoient > vers > udev (ou je ne sais trop qui) quand on demande à les lire ?
Non, ce sont des fichiers de device, ils renvoient au noyau. udev est là uniquement pour les créer et les effacer.
Ok, merci pour les explications :)
Le 22 Dec 2009 12:05:37 GMT
Nicolas George <nicolas$george@salle-s.org> a écrit :
Yliur wrote in message <20091222124923.49b9fa1f@alcheringa>:
> Je voulais dire que ce ne sont pas de vrais fichiers au sens où ils
> ne sont stockés nulle part. Ce sont des entrées
> <suppr>virtuelles</suppr> pour rire dans l'arborescence des
> fichiers.
Si, ils sont bien stockés quelque part : ils sont stockés dans le
filesystem tmpfs monté dans /dev. Ce filesystem réside en RAM et pas
sur un block device, mais c'est un filesystem à part entière. Tu peux
y mettre les fichiers que tu veux, y compris des fichiers réguliers.
> C'est mal de dire "virtuels" ? On peut confondre avec autre chose ?
Oui. Les entrées dans procfs et sysfs sont elles plus exactement
virtuelles, il n'y a pas de stockage, les listes et les contenus sont
générés à la volée à partir des structures de données du no yau.
C'est aussi vrai pour devfs des noyaux 2.4, même si c'était un peu
intermédiaire, puisque les noms et les droits étaient stockés à p art
entière, de même d'ailleurs que des liens symboliques et des sockets.
> Mmmm... Une question en passant : comment udev fait pour créer des
> fichiers qui n'existent pas ?
Avec mknod, comme tout le monde.
> J'imagine qu'il doit
> obligatoirement
> demander un service au noyau, non ?
Oui, mais ce n'est pas le noyau qui prend l'initiative.
> Tu disais qu'ils étaient
> "temporaires" plutôt que "virtuels". Est-ce que ce sont des noeuds
> réellement ajoutés au système de fichiers
Oui, mais le système de fichiers tmpfs monté dans /dev.
> mais qui renvoient
> vers
> udev (ou je ne sais trop qui) quand on demande à les lire ?
Non, ce sont des fichiers de device, ils renvoient au noyau. udev est
là uniquement pour les créer et les effacer.
Le 22 Dec 2009 12:05:37 GMT Nicolas George <nicolas$ a écrit :
Yliur wrote in message : > Je voulais dire que ce ne sont pas de vrais fichiers au sens où ils > ne sont stockés nulle part. Ce sont des entrées > <suppr>virtuelles</suppr> pour rire dans l'arborescence des > fichiers.
Si, ils sont bien stockés quelque part : ils sont stockés dans le filesystem tmpfs monté dans /dev. Ce filesystem réside en RAM et pas sur un block device, mais c'est un filesystem à part entière. Tu peux y mettre les fichiers que tu veux, y compris des fichiers réguliers.
> C'est mal de dire "virtuels" ? On peut confondre avec autre chose ?
Oui. Les entrées dans procfs et sysfs sont elles plus exactement virtuelles, il n'y a pas de stockage, les listes et les contenus sont générés à la volée à partir des structures de données du no yau.
C'est aussi vrai pour devfs des noyaux 2.4, même si c'était un peu intermédiaire, puisque les noms et les droits étaient stockés à p art entière, de même d'ailleurs que des liens symboliques et des sockets.
> Mmmm... Une question en passant : comment udev fait pour créer des > fichiers qui n'existent pas ?
Avec mknod, comme tout le monde.
> J'imagine qu'il doit > obligatoirement > demander un service au noyau, non ?
Oui, mais ce n'est pas le noyau qui prend l'initiative.
> Tu disais qu'ils étaient > "temporaires" plutôt que "virtuels". Est-ce que ce sont des noeuds > réellement ajoutés au système de fichiers
Oui, mais le système de fichiers tmpfs monté dans /dev.
> mais qui renvoient > vers > udev (ou je ne sais trop qui) quand on demande à les lire ?
Non, ce sont des fichiers de device, ils renvoient au noyau. udev est là uniquement pour les créer et les effacer.
Ok, merci pour les explications :)
Yliur
Le 22 Dec 2009 12:30:08 GMT Nicolas George <nicolas$ a écrit :
Yliur wrote in message : > C'est vrai que si sa partition peut être montée automatiquement et > que ça permet de contourner le problème c'est une bonne solution > pratique, mais c'est quand même bien de savoir pourquoi pour > avancer dans sa compréhension du bidule...
La compréhension du bidule, ça commence par savoir discerner les bons objectifs des mauvais.
Mouais... Note que je ne dis pas que ta remarque était mauvaise, tu as raison d'évoquer d'autres possibilité, mais ça devrait être possi ble ce qu'il veut faire, et donc c'est normal qu'il ait envie de comprendre comment.
Le 22 Dec 2009 12:30:08 GMT
Nicolas George <nicolas$george@salle-s.org> a écrit :
Yliur wrote in message <20091222125252.5150952b@alcheringa>:
> C'est vrai que si sa partition peut être montée automatiquement et
> que ça permet de contourner le problème c'est une bonne solution
> pratique, mais c'est quand même bien de savoir pourquoi pour
> avancer dans sa compréhension du bidule...
La compréhension du bidule, ça commence par savoir discerner les bons
objectifs des mauvais.
Mouais... Note que je ne dis pas que ta remarque était mauvaise, tu as
raison d'évoquer d'autres possibilité, mais ça devrait être possi ble
ce qu'il veut faire, et donc c'est normal qu'il ait envie de
comprendre comment.
Le 22 Dec 2009 12:30:08 GMT Nicolas George <nicolas$ a écrit :
Yliur wrote in message : > C'est vrai que si sa partition peut être montée automatiquement et > que ça permet de contourner le problème c'est une bonne solution > pratique, mais c'est quand même bien de savoir pourquoi pour > avancer dans sa compréhension du bidule...
La compréhension du bidule, ça commence par savoir discerner les bons objectifs des mauvais.
Mouais... Note que je ne dis pas que ta remarque était mauvaise, tu as raison d'évoquer d'autres possibilité, mais ça devrait être possi ble ce qu'il veut faire, et donc c'est normal qu'il ait envie de comprendre comment.
Sergio
Nicolas George a écrit :
Et alors ?
Pour l'autre question, c'est recommandé par la doc de ntfs-3g de faire un chmod 4755 sur /usr/bin/ntfs-3g pour pouvoir l'utiliser en mode utilisateur.
Et pourquoi vouloir l'utiliser « en mode utilisateur » (ce qui, soit dit en passant, est du charabia).
Pour ne pas avoir à s'appeler "root" pour le monter et y accéder.
-- Serge http://leserged.online.fr/ Mon blog: http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
Nicolas George a écrit :
Et alors ?
Pour l'autre question, c'est recommandé par la doc de ntfs-3g de faire un
chmod 4755 sur /usr/bin/ntfs-3g pour pouvoir l'utiliser en mode
utilisateur.
Et pourquoi vouloir l'utiliser « en mode utilisateur » (ce qui, soit dit en
passant, est du charabia).
Pour ne pas avoir à s'appeler "root" pour le monter et y accéder.
--
Serge http://leserged.online.fr/
Mon blog: http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org
