Bonjour,
J'ai voulu voir si Clone X pouvait remplacer l'excellent BootCD qui nous
a lâchés (quand je voyage avec mon iBook j'aime bien avoir de quoi
tester/réparer sous la main).
Après création d'une image de DVD bootable avec Clone X, FinderPop m'a
montré l'apparition de choses bizarres dans le Desktop, invisibles à
l'écran. Le Terminal me montre l'apparition au niveau Volumes, en plus
de mes 3 partitions, de 3 trucs qui n'ont rien à faire là :
[iMac:/Volumes] henri% ls -a
. .DS_Store DDur bin sbin
.. DDX SOS mach_kernel
En poussant un peu l'investigation je trouve :
[iMac:/Volumes] henri% ls -al
total 8528
drwxrwxrwt 9 root admin 306 Feb 17 11:23 .
drwxrwxr-t 40 root admin 1462 Feb 17 11:21 ..
-rw-rw-rw- 1 henri admin 6148 Feb 17 10:37 .DS_Store
lrwxr-xr-x 1 root admin 1 Feb 17 11:21 DDX -> /
drwxrwxr-x 29 root admin 1020 Feb 14 19:42 DDur
drwxrwxr-t 36 root admin 1258 Feb 17 10:54 SOS
drwxr-xr-x 40 root wheel 1360 Jan 9 12:11 bin
-rw-r--r-- 1 root wheel 4352200 Oct 11 2007 mach_kernel
drwxr-xr-x 63 root wheel 2142 Jan 9 12:11 sbin
[iMac:/Volumes] henri%
Que signifie la 4ème ligne ?
Est-ce une sorte d'alias dont la suppression ou la modification mettrait
fin à ce bazar ?
Je n'ose pas supprimer bin, sbin et mach_kernel car j'ai l'impression
qu'il s'agit des vrais dossiers/fichiers, qu'ils n'ont pas été
réellement déplacés ou dupliqués et que seule une étrange action de
Clone X les fait apparaître là.
Utilitaire de Disque, DiskWarrior et TTPro ne disent rien. Et cela
m'ennuirait de devoir ré-installer tout pour probablement pas grand
chose.
Merci de votre aide et de vos idées. En tous cas Clone X me semble une
drôle de bestiole.
HC
Existe t-il un bouquin ou un site assez didactique sur cet Unix particulier utilisé par OS X ? J'aimerais avoir un manuel où, sans apprendre tout par c½ur, on puisse assez facilement savoir où trouver les outils pour évaluer le problème du moment.
L'Unix utilisé par Mac OS X n'a rien de particulier. Tout ce que j'ai dit ici (sauf la création du lien DXX vers ton volume principal) est vrai pour n'importe quel Unix ou Linux. Les manuels sur Unix sont en général assez gros et touffu.
Une bonne recherche sur Google te permettrait de trouver des infos qui peuvent être suffisante. Par exemple : <http://www.google.com/search?hl=fr&client=firefox-a&rls=org.mozilla%3Af r%3Aofficial&hs=4vi&q=manuel+unix&btnG=Rechercher&lr=>
Parmi les premiers résultats trouvés, celui-ci (en deux parties) : <http://www.softndesign.org/manuels/unix-1.html> <http://www.softndesign.org/manuels/unix-2.html>
semble assez intéressant. Par contre en ce qui concerne les liens il ne connait que les liens symboliques ;-(
Pour les liens, une autre recherche : <http://www.google.com/search?q=liens+unix&ie=utf-8&oe=utf-8&aq=t&rls=or g.mozilla:fr:official&client=firefox-a>
donne les résultats intéressants suivants : <http://fr.wikipedia.org/wiki/Ln_%28Unix%29> <http://www.shellunix.com/commandes.html> <http://www.commentcamarche.net/contents/unix/unix-fichiers.php3>
Si vraiment tu veux des livres : Christian Pélissier - Unix - réf 9782866014490 JMarie-Rifflet - Programmation sous Unix - ISBN 2-84074-013-3
Mais si c'est pour avoir des infos sur tel ou tel point particulier, je pense qu'une recherche Google est bien plus efficace.
-- JiPaul. / /--/--// Jean-Paul Blanc |/| L | quelquepart en (somewhere in) /|| = ||| FRANCE
Henri <yapersonne@nowhere.com> wrote:
Existe t-il un bouquin ou un site assez didactique sur cet Unix
particulier utilisé par OS X ? J'aimerais avoir un manuel où, sans
apprendre tout par c½ur, on puisse assez facilement savoir où trouver
les outils pour évaluer le problème du moment.
L'Unix utilisé par Mac OS X n'a rien de particulier. Tout ce que j'ai
dit ici (sauf la création du lien DXX vers ton volume principal) est
vrai pour n'importe quel Unix ou Linux. Les manuels sur Unix sont en
général assez gros et touffu.
Une bonne recherche sur Google te permettrait de trouver des infos qui
peuvent être suffisante. Par exemple :
<http://www.google.com/search?hl=fr&client=firefox-a&rls=org.mozilla%3Af
r%3Aofficial&hs=4vi&q=manuel+unix&btnG=Rechercher&lr=>
Parmi les premiers résultats trouvés, celui-ci (en deux parties) :
<http://www.softndesign.org/manuels/unix-1.html>
<http://www.softndesign.org/manuels/unix-2.html>
semble assez intéressant. Par contre en ce qui concerne les liens il ne
connait que les liens symboliques ;-(
Pour les liens, une autre recherche :
<http://www.google.com/search?q=liens+unix&ie=utf-8&oe=utf-8&aq=t&rls=or
g.mozilla:fr:official&client=firefox-a>
donne les résultats intéressants suivants :
<http://fr.wikipedia.org/wiki/Ln_%28Unix%29>
<http://www.shellunix.com/commandes.html>
<http://www.commentcamarche.net/contents/unix/unix-fichiers.php3>
Si vraiment tu veux des livres :
Christian Pélissier - Unix - réf 9782866014490
JMarie-Rifflet - Programmation sous Unix - ISBN 2-84074-013-3
Mais si c'est pour avoir des infos sur tel ou tel point particulier, je
pense qu'une recherche Google est bien plus efficace.
--
JiPaul.
/ /--/--//\ Jean-Paul Blanc
|/| L |\ quelquepart en (somewhere in)
/|| = |||\ FRANCE
Existe t-il un bouquin ou un site assez didactique sur cet Unix particulier utilisé par OS X ? J'aimerais avoir un manuel où, sans apprendre tout par c½ur, on puisse assez facilement savoir où trouver les outils pour évaluer le problème du moment.
L'Unix utilisé par Mac OS X n'a rien de particulier. Tout ce que j'ai dit ici (sauf la création du lien DXX vers ton volume principal) est vrai pour n'importe quel Unix ou Linux. Les manuels sur Unix sont en général assez gros et touffu.
Une bonne recherche sur Google te permettrait de trouver des infos qui peuvent être suffisante. Par exemple : <http://www.google.com/search?hl=fr&client=firefox-a&rls=org.mozilla%3Af r%3Aofficial&hs=4vi&q=manuel+unix&btnG=Rechercher&lr=>
Parmi les premiers résultats trouvés, celui-ci (en deux parties) : <http://www.softndesign.org/manuels/unix-1.html> <http://www.softndesign.org/manuels/unix-2.html>
semble assez intéressant. Par contre en ce qui concerne les liens il ne connait que les liens symboliques ;-(
Pour les liens, une autre recherche : <http://www.google.com/search?q=liens+unix&ie=utf-8&oe=utf-8&aq=t&rls=or g.mozilla:fr:official&client=firefox-a>
donne les résultats intéressants suivants : <http://fr.wikipedia.org/wiki/Ln_%28Unix%29> <http://www.shellunix.com/commandes.html> <http://www.commentcamarche.net/contents/unix/unix-fichiers.php3>
Si vraiment tu veux des livres : Christian Pélissier - Unix - réf 9782866014490 JMarie-Rifflet - Programmation sous Unix - ISBN 2-84074-013-3
Mais si c'est pour avoir des infos sur tel ou tel point particulier, je pense qu'une recherche Google est bien plus efficace.
-- JiPaul. / /--/--// Jean-Paul Blanc |/| L | quelquepart en (somewhere in) /|| = ||| FRANCE
yapersonne
JiPaul wrote:
Si vraiment tu veux des livres :
Pas particulièrement car en effet ce que j'ai vu était touffu, avec un côté pavé universel décourageant pour mes besoins. Et la lecture des man est un peu aride. Je songeais plutôt à un genre aide-mémoire un peu amélioré, avec explications et exemples. J'ai un PDF "Unix in 24 hours" bien fichu de ce point de vue mais un peu court quand même.
Mais si c'est pour avoir des infos sur tel ou tel point particulier, je pense qu'une recherche Google est bien plus efficace.
C'est sans doute juste. Je vais aller voir ces liens et j'archive aussi cette liste. Merci HC
JiPaul <blanc@empty.org> wrote:
Si vraiment tu veux des livres :
Pas particulièrement car en effet ce que j'ai vu était touffu, avec un
côté pavé universel décourageant pour mes besoins. Et la lecture des man
est un peu aride. Je songeais plutôt à un genre aide-mémoire un peu
amélioré, avec explications et exemples. J'ai un PDF "Unix in 24 hours"
bien fichu de ce point de vue mais un peu court quand même.
Mais si c'est pour avoir des infos sur tel ou tel point particulier, je
pense qu'une recherche Google est bien plus efficace.
C'est sans doute juste. Je vais aller voir ces liens et j'archive aussi
cette liste.
Merci
HC
Pas particulièrement car en effet ce que j'ai vu était touffu, avec un côté pavé universel décourageant pour mes besoins. Et la lecture des man est un peu aride. Je songeais plutôt à un genre aide-mémoire un peu amélioré, avec explications et exemples. J'ai un PDF "Unix in 24 hours" bien fichu de ce point de vue mais un peu court quand même.
Mais si c'est pour avoir des infos sur tel ou tel point particulier, je pense qu'une recherche Google est bien plus efficace.
C'est sans doute juste. Je vais aller voir ces liens et j'archive aussi cette liste. Merci HC
Paul Gaborit
À (at) Thu, 18 Feb 2010 10:17:13 +0100, (JiPaul) écrivait (wrote):
Paul Gaborit wrote:
Il faut utiliser l'option '-i' de la commande 'ls' pour voir les numéros d'inode (les numéros des fichiers sur le disque) :
ls -ldi /mach_kernel ls -ldi /Volumes/HDD/mach_kernel
Oui. Option -i pour voir les numéros d'inodes. Mais pourquoi donc -d ? mach_kernel est un fichier, ce n'est pas un dossier. Et dans le cas des deux dossiers bin et sbin, on ne peut pas avoir d'autres liens physiques vers des dossiers (sauf les liens .. qui sont dans les dossiers fils, et le lien . dans lui-même) que le lien principal.
Pour HFS+, je n'en suis pas sûr mais dans de nombreux systèmes de fichiers Unix, il est juste déconseillé de faire des liens hards pour les répertoires à tel point que seul root à le droit de le faire...
Petit extrait de la page de man de 'ln' sur Mac OS X :
By default, ln makes hard links. A hard link to a file is indistinguish- able from the original directory entry; any changes to a file are effec- tively independent of the name used to reference the file. Hard links may not normally refer to directories and may not span file systems.
Notez l'emploi de 'may not normally' dans la dernière phrase.
(Si votre disque s'appelle HDD.) Et là, vous verrez que ce sont bien les mêmes fichiers car le numéro d'inode d'un fichier est unique même si le fichier apparaît en plusieurs endroits.
En fait si c'était le cas le nombre de liens physiques serait différent de 1 (je parle de mach_kernel) :
-rw-r--r-- 1 root wheel 4352200 Oct 11 2007 mach_kernel
Il serait différent de 1 dans le cas d'un lien dur (hard) entre les deux noms. Mais comme /Volumes/HDD est un lien symbolique vers /, le nombres de liens durs de mach_kernel reste à 1 et pourtant on voit bien le même fichier en deux endroits différents de l'arborescence.
L'autre méthode de véfification consiste à effacer ou renommer l'un de ces fichiers/dossiers et à vérifier que son "double" a aussi disparu...
Ben non, justement il ne disparaîtrait pas, même si c'était un lien physique vers le même fichier.
Sauf si on est dans la situation exposée ci-dessus où le fichier n'a qu'un lien dur et qui est exactement ce que fait Mac OS X avec le disque de démarrage.
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Thu, 18 Feb 2010 10:17:13 +0100,
blanc@empty.org (JiPaul) écrivait (wrote):
Paul Gaborit <Paul.Gaborit@invalid.invalid> wrote:
Il faut utiliser l'option '-i' de la commande 'ls' pour voir les
numéros d'inode (les numéros des fichiers sur le disque) :
ls -ldi /mach_kernel
ls -ldi /Volumes/HDD/mach_kernel
Oui. Option -i pour voir les numéros d'inodes.
Mais pourquoi donc -d ? mach_kernel est un fichier, ce n'est pas un
dossier. Et dans le cas des deux dossiers bin et sbin, on ne peut pas
avoir d'autres liens physiques vers des dossiers (sauf les liens .. qui
sont dans les dossiers fils, et le lien . dans lui-même) que le lien
principal.
Pour HFS+, je n'en suis pas sûr mais dans de nombreux systèmes de
fichiers Unix, il est juste déconseillé de faire des liens hards pour
les répertoires à tel point que seul root à le droit de le faire...
Petit extrait de la page de man de 'ln' sur Mac OS X :
By default, ln makes hard links. A hard link to a file is
indistinguish- able from the original directory entry; any
changes to a file are effec- tively independent of the name used
to reference the file. Hard links may not normally refer to
directories and may not span file systems.
Notez l'emploi de 'may not normally' dans la dernière phrase.
(Si votre disque s'appelle HDD.) Et là, vous verrez que ce sont bien
les mêmes fichiers car le numéro d'inode d'un fichier est unique même
si le fichier apparaît en plusieurs endroits.
En fait si c'était le cas le nombre de liens physiques serait différent
de 1 (je parle de mach_kernel) :
-rw-r--r-- 1 root wheel 4352200 Oct 11 2007 mach_kernel
Il serait différent de 1 dans le cas d'un lien dur (hard) entre les
deux noms. Mais comme /Volumes/HDD est un lien symbolique vers /, le
nombres de liens durs de mach_kernel reste à 1 et pourtant on voit
bien le même fichier en deux endroits différents de l'arborescence.
L'autre méthode de véfification consiste à effacer ou renommer l'un de
ces fichiers/dossiers et à vérifier que son "double" a aussi
disparu...
Ben non, justement il ne disparaîtrait pas, même si c'était un lien
physique vers le même fichier.
Sauf si on est dans la situation exposée ci-dessus où le fichier n'a
qu'un lien dur et qui est exactement ce que fait Mac OS X avec le
disque de démarrage.
--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Thu, 18 Feb 2010 10:17:13 +0100, (JiPaul) écrivait (wrote):
Paul Gaborit wrote:
Il faut utiliser l'option '-i' de la commande 'ls' pour voir les numéros d'inode (les numéros des fichiers sur le disque) :
ls -ldi /mach_kernel ls -ldi /Volumes/HDD/mach_kernel
Oui. Option -i pour voir les numéros d'inodes. Mais pourquoi donc -d ? mach_kernel est un fichier, ce n'est pas un dossier. Et dans le cas des deux dossiers bin et sbin, on ne peut pas avoir d'autres liens physiques vers des dossiers (sauf les liens .. qui sont dans les dossiers fils, et le lien . dans lui-même) que le lien principal.
Pour HFS+, je n'en suis pas sûr mais dans de nombreux systèmes de fichiers Unix, il est juste déconseillé de faire des liens hards pour les répertoires à tel point que seul root à le droit de le faire...
Petit extrait de la page de man de 'ln' sur Mac OS X :
By default, ln makes hard links. A hard link to a file is indistinguish- able from the original directory entry; any changes to a file are effec- tively independent of the name used to reference the file. Hard links may not normally refer to directories and may not span file systems.
Notez l'emploi de 'may not normally' dans la dernière phrase.
(Si votre disque s'appelle HDD.) Et là, vous verrez que ce sont bien les mêmes fichiers car le numéro d'inode d'un fichier est unique même si le fichier apparaît en plusieurs endroits.
En fait si c'était le cas le nombre de liens physiques serait différent de 1 (je parle de mach_kernel) :
-rw-r--r-- 1 root wheel 4352200 Oct 11 2007 mach_kernel
Il serait différent de 1 dans le cas d'un lien dur (hard) entre les deux noms. Mais comme /Volumes/HDD est un lien symbolique vers /, le nombres de liens durs de mach_kernel reste à 1 et pourtant on voit bien le même fichier en deux endroits différents de l'arborescence.
L'autre méthode de véfification consiste à effacer ou renommer l'un de ces fichiers/dossiers et à vérifier que son "double" a aussi disparu...
Ben non, justement il ne disparaîtrait pas, même si c'était un lien physique vers le même fichier.
Sauf si on est dans la situation exposée ci-dessus où le fichier n'a qu'un lien dur et qui est exactement ce que fait Mac OS X avec le disque de démarrage.
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
blanc
JiPaul wrote:
Pour les liens, une autre recherche : <http://www.google.com/search?q=liens+unix&ie=utf-8&oe=utf-8&aq=t&rls=or g.mozilla:fr:official&client=firefox-a>
donne les résultats intéressants suivants : <http://fr.wikipedia.org/wiki/Ln_%28Unix%29> <http://www.shellunix.com/commandes.html> <http://www.commentcamarche.net/contents/unix/unix-fichiers.php3>
Et un autre qui décrit très bien les deux sortes de liens (si tu ne crains pas l'anglais) : <http://linuxgazette.net/105/pitcher.html>
-- JiPaul. / /--/--// Jean-Paul Blanc |/| L | quelquepart en (somewhere in) /|| = ||| FRANCE
JiPaul <blanc@empty.org> wrote:
Pour les liens, une autre recherche :
<http://www.google.com/search?q=liens+unix&ie=utf-8&oe=utf-8&aq=t&rls=or
g.mozilla:fr:official&client=firefox-a>
donne les résultats intéressants suivants :
<http://fr.wikipedia.org/wiki/Ln_%28Unix%29>
<http://www.shellunix.com/commandes.html>
<http://www.commentcamarche.net/contents/unix/unix-fichiers.php3>
Et un autre qui décrit très bien les deux sortes de liens (si tu ne
crains pas l'anglais) :
<http://linuxgazette.net/105/pitcher.html>
--
JiPaul.
/ /--/--//\ Jean-Paul Blanc
|/| L |\ quelquepart en (somewhere in)
/|| = |||\ FRANCE
Pour les liens, une autre recherche : <http://www.google.com/search?q=liens+unix&ie=utf-8&oe=utf-8&aq=t&rls=or g.mozilla:fr:official&client=firefox-a>
donne les résultats intéressants suivants : <http://fr.wikipedia.org/wiki/Ln_%28Unix%29> <http://www.shellunix.com/commandes.html> <http://www.commentcamarche.net/contents/unix/unix-fichiers.php3>
Et un autre qui décrit très bien les deux sortes de liens (si tu ne crains pas l'anglais) : <http://linuxgazette.net/105/pitcher.html>
-- JiPaul. / /--/--// Jean-Paul Blanc |/| L | quelquepart en (somewhere in) /|| = ||| FRANCE
blanc
Paul Gaborit wrote:
Pour HFS+, je n'en suis pas sûr mais dans de nombreux systèmes de fichiers Unix, il est juste déconseillé de faire des liens hards pour les répertoires à tel point que seul root à le droit de le faire...
A ça, je ne savais pas. Je n'arrive pas à en faire sous Mac OS X, même avec sudo, mais peut-être y a-t-il une option cachée pour le faire ?...
Petit extrait de la page de man de 'ln' sur Mac OS X :
By default, ln makes hard links. A hard link to a file is indistinguish- able from the original directory entry; any changes to a file are effec- tively independent of the name used to reference the file. Hard links may not normally refer to directories and may not span file systems.
OK.
>> (Si votre disque s'appelle HDD.) Et là, vous verrez que ce sont bien >> les mêmes fichiers car le numéro d'inode d'un fichier est unique même >> si le fichier apparaît en plusieurs endroits. > > En fait si c'était le cas le nombre de liens physiques serait différent > de 1 (je parle de mach_kernel) : > > -rw-r--r-- 1 root wheel 4352200 Oct 11 2007 mach_kernel
Il serait différent de 1 dans le cas d'un lien dur (hard) entre les deux noms. Mais comme /Volumes/HDD est un lien symbolique vers /, le nombres de liens durs de mach_kernel reste à 1 et pourtant on voit bien le même fichier en deux endroits différents de l'arborescence.
C'est vrai, j'avais oublié cette possibilité. Mais en l'occurence, pour que /Volumes/mach_kernel soit le même fichier que /mach_kernel il faudrait (il me semble) que /Volumes soit un lien symbolique vers /, ce qui n'est pas le cas.
>> L'autre méthode de véfification consiste à effacer ou renommer l'un de >> ces fichiers/dossiers et à vérifier que son "double" a aussi >> disparu... > > Ben non, justement il ne disparaîtrait pas, même si c'était un lien > physique vers le même fichier.
Sauf si on est dans la situation exposée ci-dessus où le fichier n'a qu'un lien dur et qui est exactement ce que fait Mac OS X avec le disque de démarrage.
Dans ce cas, oui. -- JiPaul. / /--/--// Jean-Paul Blanc |/| L | quelquepart en (somewhere in) /|| = ||| FRANCE
Paul Gaborit <Paul.Gaborit@invalid.invalid> wrote:
Pour HFS+, je n'en suis pas sûr mais dans de nombreux systèmes de
fichiers Unix, il est juste déconseillé de faire des liens hards pour
les répertoires à tel point que seul root à le droit de le faire...
A ça, je ne savais pas. Je n'arrive pas à en faire sous Mac OS X, même
avec sudo, mais peut-être y a-t-il une option cachée pour le faire ?...
Petit extrait de la page de man de 'ln' sur Mac OS X :
By default, ln makes hard links. A hard link to a file is
indistinguish- able from the original directory entry; any
changes to a file are effec- tively independent of the name used
to reference the file. Hard links may not normally refer to
directories and may not span file systems.
OK.
>> (Si votre disque s'appelle HDD.) Et là, vous verrez que ce sont bien
>> les mêmes fichiers car le numéro d'inode d'un fichier est unique même
>> si le fichier apparaît en plusieurs endroits.
>
> En fait si c'était le cas le nombre de liens physiques serait différent
> de 1 (je parle de mach_kernel) :
>
> -rw-r--r-- 1 root wheel 4352200 Oct 11 2007 mach_kernel
Il serait différent de 1 dans le cas d'un lien dur (hard) entre les
deux noms. Mais comme /Volumes/HDD est un lien symbolique vers /, le
nombres de liens durs de mach_kernel reste à 1 et pourtant on voit
bien le même fichier en deux endroits différents de l'arborescence.
C'est vrai, j'avais oublié cette possibilité. Mais en l'occurence, pour
que /Volumes/mach_kernel soit le même fichier que /mach_kernel il
faudrait (il me semble) que /Volumes soit un lien symbolique vers /, ce
qui n'est pas le cas.
>> L'autre méthode de véfification consiste à effacer ou renommer l'un de
>> ces fichiers/dossiers et à vérifier que son "double" a aussi
>> disparu...
>
> Ben non, justement il ne disparaîtrait pas, même si c'était un lien
> physique vers le même fichier.
Sauf si on est dans la situation exposée ci-dessus où le fichier n'a
qu'un lien dur et qui est exactement ce que fait Mac OS X avec le
disque de démarrage.
Dans ce cas, oui.
--
JiPaul.
/ /--/--//\ Jean-Paul Blanc
|/| L |\ quelquepart en (somewhere in)
/|| = |||\ FRANCE
Pour HFS+, je n'en suis pas sûr mais dans de nombreux systèmes de fichiers Unix, il est juste déconseillé de faire des liens hards pour les répertoires à tel point que seul root à le droit de le faire...
A ça, je ne savais pas. Je n'arrive pas à en faire sous Mac OS X, même avec sudo, mais peut-être y a-t-il une option cachée pour le faire ?...
Petit extrait de la page de man de 'ln' sur Mac OS X :
By default, ln makes hard links. A hard link to a file is indistinguish- able from the original directory entry; any changes to a file are effec- tively independent of the name used to reference the file. Hard links may not normally refer to directories and may not span file systems.
OK.
>> (Si votre disque s'appelle HDD.) Et là, vous verrez que ce sont bien >> les mêmes fichiers car le numéro d'inode d'un fichier est unique même >> si le fichier apparaît en plusieurs endroits. > > En fait si c'était le cas le nombre de liens physiques serait différent > de 1 (je parle de mach_kernel) : > > -rw-r--r-- 1 root wheel 4352200 Oct 11 2007 mach_kernel
Il serait différent de 1 dans le cas d'un lien dur (hard) entre les deux noms. Mais comme /Volumes/HDD est un lien symbolique vers /, le nombres de liens durs de mach_kernel reste à 1 et pourtant on voit bien le même fichier en deux endroits différents de l'arborescence.
C'est vrai, j'avais oublié cette possibilité. Mais en l'occurence, pour que /Volumes/mach_kernel soit le même fichier que /mach_kernel il faudrait (il me semble) que /Volumes soit un lien symbolique vers /, ce qui n'est pas le cas.
>> L'autre méthode de véfification consiste à effacer ou renommer l'un de >> ces fichiers/dossiers et à vérifier que son "double" a aussi >> disparu... > > Ben non, justement il ne disparaîtrait pas, même si c'était un lien > physique vers le même fichier.
Sauf si on est dans la situation exposée ci-dessus où le fichier n'a qu'un lien dur et qui est exactement ce que fait Mac OS X avec le disque de démarrage.
Dans ce cas, oui. -- JiPaul. / /--/--// Jean-Paul Blanc |/| L | quelquepart en (somewhere in) /|| = ||| FRANCE
yapersonne
JiPaul wrote:
<http://linuxgazette.net/105/pitcher.html>
Vu, intéressant par les exemples donnés. Dommage qu'on ne trouve pas de bouquins/sites de niveau moyen avec exemples comme là, permettant de voir les actions réelles (et les c...ries avant de les faire). Mon PDF "Unix in 24 hours" fait ça mais est vraiment trop limité pour servir de boîte à outils HC
JiPaul <blanc@empty.org> wrote:
<http://linuxgazette.net/105/pitcher.html>
Vu, intéressant par les exemples donnés. Dommage qu'on ne trouve pas de
bouquins/sites de niveau moyen avec exemples comme là, permettant de
voir les actions réelles (et les c...ries avant de les faire).
Mon PDF "Unix in 24 hours" fait ça mais est vraiment trop limité pour
servir de boîte à outils
HC
Vu, intéressant par les exemples donnés. Dommage qu'on ne trouve pas de bouquins/sites de niveau moyen avec exemples comme là, permettant de voir les actions réelles (et les c...ries avant de les faire). Mon PDF "Unix in 24 hours" fait ça mais est vraiment trop limité pour servir de boîte à outils HC
