Voilà je vais un DD Sata de 500 go et je pense le partionner en 2 *250
pour installer XP puis Vista Familial.
Quand je lis cela je me pose la question de la faisabilité d'un dual boot.
"Si tu ne maîtrises pas les concepts décrits dans cet article, je te
déconseille fortement de tenter une installation en dual boot.
D'autant plus que cette technique a un inconvénient qui peut engendrer des
problèmes au cas où tu aurais besoin d'une restauration : à chaque démarrage
de XP, tous les points de sauvegardes automatiques de Vista seront détruits.
Cela est dû au fait qu'au démarrage, XP parcourt toutes les partitions de
tous les disques pour vérifier sur chacune l'intégrité du répertoire System
Volume Information qui contient les sauvegardes automatiques et en cas de
corruption de recréer les données contenues dans ces répertoires.
Le problème, c'est que Vista utilise également ce système dans les mêmes
répertoires, mais avec un format de données différent. Or ce format n'est
pas reconnu par XP, qui considère alors que les données sont corrompues, il
efface alors le contenu du répertoire en question et recrée un point de
sauvegarde, mais avec son propre format. Ainsi, à chaque démarrage sur un
des deux OS consécutif à un démarrage sur l'autre, tous les points de
restauration seront perdus."
Je ne suis pas d'accord du tout avec ton "alternative".
Une partition cachée par NTFS (Paragon) l'est pour tous les OS.
Je pense que tu veux dire "Une partition ayant son attribut de masquage à 1 est cachée pour tous les OS qui gèrent cet attribut"
En effet, les OS MICROSOFT (de DOS à NT - toute version confondue) ont "décidé" que si le bit 4 du type de la partition est mis à 1, alors la partition apparait comme "cachée". Mais cela ne concerne QUE les OS MICROSOFT !
P.ex., le type 0x55 (qui correspondRAIT à une partition de type 0x45 et cachée) est utilisé par "EZ-Drive", tandis que le type 0x45 est utilisé par "BootUS boot manager". De même, le type 0x93 (qui serait a priori une partition LINUX Ext2fs cachée) est utilisé par "Amoeba Distributed Operating System"
Nous parlions ici de cacher une partition pour l'OS en cours. C'est notamment pour éviter les écrasements de points de restauration d'un OS à l'autre en multiboot.
Ce qui me reste à vérifier, c'est si la non-attribution d'une lettre dans un OS a des répercussions (NTFS) sur un autre OS, ou non.
NON, puisque les (non)attributions de lettres sont définies dans la BDR, à savoir HKLMSystemMountedDevices, donc un fichier qui dépend de l'OS, et non pas de la structure même du disque (table de MBR, secteur de boot, ...)
Le nom (lettre) donné à une partition sous le 1er OS est indépendant du nom de cette même partition sous le 2ème. Donc cela ne sert à RIEN pour le 2ème OS !!! Le "lettrage" des différents unités de disque est stocké sous la forme d'entrées de la forme "DosDevicesK:" dans HKLMSystemMountedDevices
Petit rappel sur HKLMSystemMountedDevices : --------------------------------------------------- On y trouve un certain nombre d'entrées de type REG_BINARY de la forme ??Volume{66a5805c-c0fb-11db-bb3c-806e6f6e6963}
Cela s'appelle un "unique volume name" (UVN), qui identifie de façon UNIQUE à l'aide d'un GUID (globally unique identifier ) un volume disque. Sa valeur est composée de 12 octets, dont les 4 premiers sont la SIGNATURE du disque dur, laquelle signature se retrouve à l'offset 0x1B8 du MBR P.ex., le volume cité plus haut en exemple contient (en hexa) : 32 F2 49 15 00 7E 00 00 00 00 00 00 Et bien, dans le MBR du disque concerné, on trouve à l'offset 0x1B8: 32 F2 49 15
Les 8 autres octets (ici 00 7E 00 00 00 00 00 00) servent à identifier la partition
Chaque "unique volume name" est également identifié par des "points de montages", lesquels ont 2 syntaxes possibles : - un chemin de dossier (montage dans une partition NTFS) dans ce cas on trouve une autre entrée de type REG_BINARY de la forme #{04946041-e6c7-11dd-abec-001a92475f7f} et dont la valeur est identique à celle de l'UVN (le lien entre partition "montée" et partition "hébergeante" doit résider dans la MFT de partition "hébergeante")
- une lettre dans ce cas on trouve une autre entrée de type REG_BINARY de la forme "DosDevicesC: et dont la valeur est identique à celle de l'UVN (dans mon exemple : 32 F2 49 15 00 7E 00 00 00 00 00 00)
NB: Un volume peut avoir, au choix : - aucun point de montage (ni lettre, ni chemin de montage) - un point de montage "Lettre" (cas le plus fréquent) - un point de montage "Chemin de dossier" - un point de montage "Lettre" ET un point de montage "Chemin" MAIS il a TOUJOURS un "UVN"
-- May the Force be with You! La Connaissance s'accroît quand on la partage ---------------------------------------------------------- Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org
"Paulchen" <paul.voyerENLEVER@laposte.net> a écrit dans le message de
news:%23y673V6fJHA.4052@TK2MSFTNGP05.phx.gbl...
Merci de ta réponse, Pierre.
Je ne suis pas d'accord du tout avec ton "alternative".
Une partition cachée par NTFS (Paragon) l'est pour tous les OS.
Je pense que tu veux dire
"Une partition ayant son attribut de masquage à 1
est cachée pour tous les OS qui gèrent cet attribut"
En effet, les OS MICROSOFT (de DOS à NT - toute version confondue) ont
"décidé" que si le bit 4 du type de la partition est mis à 1, alors la
partition apparait comme "cachée".
Mais cela ne concerne QUE les OS MICROSOFT !
P.ex., le type 0x55 (qui correspondRAIT à une partition de type 0x45 et
cachée) est utilisé par "EZ-Drive", tandis que le type 0x45 est utilisé par
"BootUS boot manager".
De même, le type 0x93 (qui serait a priori une partition LINUX Ext2fs
cachée) est utilisé par "Amoeba Distributed Operating System"
Nous parlions ici de cacher une partition pour l'OS en cours.
C'est notamment pour éviter les écrasements de points de restauration
d'un OS à l'autre en multiboot.
Ce qui me reste à vérifier, c'est si la non-attribution d'une lettre dans
un OS a des répercussions (NTFS) sur un autre OS, ou non.
NON, puisque les (non)attributions de lettres sont définies dans la BDR, à
savoir HKLMSystemMountedDevices, donc un fichier qui dépend de l'OS, et
non pas de la structure même du disque (table de MBR, secteur de boot, ...)
Le nom (lettre) donné à une partition sous le 1er OS est indépendant du nom
de cette même partition sous le 2ème.
Donc cela ne sert à RIEN pour le 2ème OS !!!
Le "lettrage" des différents unités de disque est stocké sous la forme
d'entrées de la forme "DosDevicesK:" dans HKLMSystemMountedDevices
Petit rappel sur HKLMSystemMountedDevices :
---------------------------------------------------
On y trouve un certain nombre d'entrées de type REG_BINARY de la forme
??Volume{66a5805c-c0fb-11db-bb3c-806e6f6e6963}
Cela s'appelle un "unique volume name" (UVN), qui identifie de façon UNIQUE
à l'aide d'un GUID (globally unique identifier ) un volume disque.
Sa valeur est composée de 12 octets, dont les 4 premiers sont la SIGNATURE
du disque dur, laquelle signature se retrouve à l'offset 0x1B8 du MBR
P.ex., le volume cité plus haut en exemple contient (en hexa) :
32 F2 49 15 00 7E 00 00 00 00 00 00
Et bien, dans le MBR du disque concerné, on trouve à l'offset 0x1B8:
32 F2 49 15
Les 8 autres octets (ici 00 7E 00 00 00 00 00 00) servent à identifier la
partition
Chaque "unique volume name" est également identifié par des "points de
montages", lesquels ont 2 syntaxes possibles :
- un chemin de dossier (montage dans une partition NTFS)
dans ce cas on trouve une autre entrée de type REG_BINARY de la forme
#{04946041-e6c7-11dd-abec-001a92475f7f}
et dont la valeur est identique à celle de l'UVN
(le lien entre partition "montée" et partition "hébergeante"
doit résider dans la MFT de partition "hébergeante")
- une lettre
dans ce cas on trouve une autre entrée de type REG_BINARY de la forme
"DosDevicesC:
et dont la valeur est identique à celle de l'UVN
(dans mon exemple : 32 F2 49 15 00 7E 00 00 00 00 00 00)
NB: Un volume peut avoir, au choix :
- aucun point de montage (ni lettre, ni chemin de montage)
- un point de montage "Lettre" (cas le plus fréquent)
- un point de montage "Chemin de dossier"
- un point de montage "Lettre" ET un point de montage "Chemin"
MAIS il a TOUJOURS un "UVN"
--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org
Je ne suis pas d'accord du tout avec ton "alternative".
Une partition cachée par NTFS (Paragon) l'est pour tous les OS.
Je pense que tu veux dire "Une partition ayant son attribut de masquage à 1 est cachée pour tous les OS qui gèrent cet attribut"
En effet, les OS MICROSOFT (de DOS à NT - toute version confondue) ont "décidé" que si le bit 4 du type de la partition est mis à 1, alors la partition apparait comme "cachée". Mais cela ne concerne QUE les OS MICROSOFT !
P.ex., le type 0x55 (qui correspondRAIT à une partition de type 0x45 et cachée) est utilisé par "EZ-Drive", tandis que le type 0x45 est utilisé par "BootUS boot manager". De même, le type 0x93 (qui serait a priori une partition LINUX Ext2fs cachée) est utilisé par "Amoeba Distributed Operating System"
Nous parlions ici de cacher une partition pour l'OS en cours. C'est notamment pour éviter les écrasements de points de restauration d'un OS à l'autre en multiboot.
Ce qui me reste à vérifier, c'est si la non-attribution d'une lettre dans un OS a des répercussions (NTFS) sur un autre OS, ou non.
NON, puisque les (non)attributions de lettres sont définies dans la BDR, à savoir HKLMSystemMountedDevices, donc un fichier qui dépend de l'OS, et non pas de la structure même du disque (table de MBR, secteur de boot, ...)
Le nom (lettre) donné à une partition sous le 1er OS est indépendant du nom de cette même partition sous le 2ème. Donc cela ne sert à RIEN pour le 2ème OS !!! Le "lettrage" des différents unités de disque est stocké sous la forme d'entrées de la forme "DosDevicesK:" dans HKLMSystemMountedDevices
Petit rappel sur HKLMSystemMountedDevices : --------------------------------------------------- On y trouve un certain nombre d'entrées de type REG_BINARY de la forme ??Volume{66a5805c-c0fb-11db-bb3c-806e6f6e6963}
Cela s'appelle un "unique volume name" (UVN), qui identifie de façon UNIQUE à l'aide d'un GUID (globally unique identifier ) un volume disque. Sa valeur est composée de 12 octets, dont les 4 premiers sont la SIGNATURE du disque dur, laquelle signature se retrouve à l'offset 0x1B8 du MBR P.ex., le volume cité plus haut en exemple contient (en hexa) : 32 F2 49 15 00 7E 00 00 00 00 00 00 Et bien, dans le MBR du disque concerné, on trouve à l'offset 0x1B8: 32 F2 49 15
Les 8 autres octets (ici 00 7E 00 00 00 00 00 00) servent à identifier la partition
Chaque "unique volume name" est également identifié par des "points de montages", lesquels ont 2 syntaxes possibles : - un chemin de dossier (montage dans une partition NTFS) dans ce cas on trouve une autre entrée de type REG_BINARY de la forme #{04946041-e6c7-11dd-abec-001a92475f7f} et dont la valeur est identique à celle de l'UVN (le lien entre partition "montée" et partition "hébergeante" doit résider dans la MFT de partition "hébergeante")
- une lettre dans ce cas on trouve une autre entrée de type REG_BINARY de la forme "DosDevicesC: et dont la valeur est identique à celle de l'UVN (dans mon exemple : 32 F2 49 15 00 7E 00 00 00 00 00 00)
NB: Un volume peut avoir, au choix : - aucun point de montage (ni lettre, ni chemin de montage) - un point de montage "Lettre" (cas le plus fréquent) - un point de montage "Chemin de dossier" - un point de montage "Lettre" ET un point de montage "Chemin" MAIS il a TOUJOURS un "UVN"
-- May the Force be with You! La Connaissance s'accroît quand on la partage ---------------------------------------------------------- Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org
