Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Windows Windows XP Discussions Générales Infos au sujet du dossier " i386 "

Infos au sujet du dossier " i386 "

18 réponses
Avatar
Fabrice
bonjour !

Pouvez-vous me dire si le dossier i386 ( situé dans
C:\Windows\ServicePackFiles ) n'est qu'un dossier de sauvegarde, ou bien
est-ce que windows s'en sert régulièrement...?

merci !
Signaler un problème avec ce contenu

8 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2
Avatar
Laurent Jumet
Hello Lucie !

Lucie van Pelt wrote:

Lucie van Pelt, Consultations Psychiâtriques 5 ¢


Si tu écris en iso-8859-15 au lieu de iso-8859-1, tu pourras dorénavant facturer en Euros (¤) au lieu de Cents (¢).

--
Laurent Jumet - Point de Chat, Liège, BELGIUM
KeyID: 0xCFAF704C
[Restore address to laurent.jumet for e-mail reply.]

Avatar
K8lap
Bonjour à tous,

Si on possède un autre disque (local ou réseau), avec suffisamment
d'espace libre, il suffit de DÉPLACER le dossier "ServicePackFiles" sur
cette partition (ou partage réseau), et modifier la BDR afin que Windows
sache où "ServicePackFiles" réside désormais :

HKLMSOFTWAREMi­crosoftWindowsCurrentVersion­Setup
Entrées de type REG_SZ :
"ServicePackCachePath"
doit contenir :
Le-chemin-complet-de-ServicePa­ckFilesServicePackCache

"ServicePackSourcePath"
doit contenir :
Le-chemin-complet-de-ServicePa­ckFiles


Méthode intéressante!
Personnellement j'utilise la notion de lien (link). Je déplace le répertoire
i386 vers un autre disque dur/partition (réservé à des fichiers rarement
lus)
et je crée à la place du répertoire i386 d'origine un lien répertoire
pointant vers l'autre disque... Ce qui évite de passer par la base de
registre... (qui reste toujours pour moi un mystère)

exemple:
org: C:WINDOWSi386
déplacé E:BackUpWindowsI386
lien C:WINDOWSi386 pointant vers E:BackUpWindowsI386

Cette situation me permet de minimiser la partition OS et en facilite les
backups DriveImage. (moins gros)

Pouvez-vous me dire si ma méthode comporte un inconvénient?

Bonne journée.

JMP

Avatar
Jean-Claude BELLAMY
Dans le message :453dd80d$0$31913$,
K8lap a pris la peine d'écrire ce qui suit :
Bonjour à tous,

Si on possède un autre disque (local ou réseau), avec suffisamment
d'espace libre, il suffit de DÉPLACER le dossier "ServicePackFiles"
sur cette partition (ou partage réseau), et modifier la BDR afin que
Windows sache où "ServicePackFiles" réside désormais :

HKLMSOFTWAREMi­crosoftWindowsCurrentVersion­Setup
Entrées de type REG_SZ :
"ServicePackCachePath"
doit contenir :
Le-chemin-complet-de-ServicePa­ckFilesServicePackCache

"ServicePackSourcePath"
doit contenir :
Le-chemin-complet-de-ServicePa­ckFiles


Méthode intéressante!
Personnellement j'utilise la notion de lien (link). Je déplace le
répertoire i386 vers un autre disque dur/partition (réservé à des
fichiers rarement lus)
et je crée à la place du répertoire i386 d'origine un lien répertoire
pointant vers l'autre disque... Ce qui évite de passer par la base de
registre... (qui reste toujours pour moi un mystère)


Ce n'est rien d'autre qu'une (très) grosse base de données, ayant une
structure arborescente ...
Et très LOGIQUE !



exemple:
org: C:WINDOWSi386
déplacé E:BackUpWindowsI386
lien C:WINDOWSi386 pointant vers E:BackUpWindowsI386

Cette situation me permet de minimiser la partition OS et en facilite
les backups DriveImage. (moins gros)

Pouvez-vous me dire si ma méthode comporte un inconvénient?


Tu parles bien de "lien" (hardlink) n'est-ce pas ?
Obtenu par la fonction CREATEDIRECTORY et à la structure
FSCTL_SET_REPARSE_POINT ...
Que l'on trouve dans l'outil "JUNCTION" de Mark Russinovich
http://www.sysinternals.com/utilities/junction.html

Si c'est bien cela, pas de problème...


Mais au niveau complexité, je doute que ce soit plus simple qu'une simple
modif de clef dans la BDR !!! ;-)

--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP]
http://www.bellamyjc.org ou http://jc.bellamy.free.fr


Avatar
Lucie van Pelt

Hello Lucie !

Lucie van Pelt wrote:

[1 ligne citée masquée]


Si tu écris en iso-8859-15 au lieu de iso-8859-1, tu pourras dorénavant facturer en Euros (¤) au lieu de Cents (¢).


Tu as besoin d'une consultation toi aussi p'tit gars ?
Ce sera 10 centimes !

:-¤

--

Lucie van Pelt, Consultations Psychiâtriques 5 ¢


Avatar
K8lap
RE! comme dit si bien Guy Bedos... (dans le sens de re-bonjour)

Personnellement j'utilise la notion de lien (link). Je déplace le
répertoire i386 vers un autre disque dur/partition (réservé à des
fichiers rarement lus)
et je crée à la place du répertoire i386 d'origine un lien répertoire
pointant vers l'autre disque... Ce qui évite de passer par la base de
registre... (qui reste toujours pour moi un mystère)


Ce n'est rien d'autre qu'une (très) grosse base de données, ayant une
structure arborescente ...
Et très LOGIQUE !


Je n'ai rien contre cette structure de base de données, mais quand on veut
modifier/rechercher quelquechose, on est incapable de savoir quoi et où
chercher. Les infos sont éparpillées n'importe où... il faut d'abord
connaître les mots clés.
Dans l'exemple cité, comment deviner que le mot clé ServicePackSourcePath
existe? Il faut d'abord avoir la connaissance avant de trouver
l'information! C'est une bonne méthode pour empêcher les gens de comprendre
les choses...
Cela me déroute beaucoup car ce n'est pas mon mode de pensée! Je préfère de
beaucoup la notion de fichier .ini, où les informations se trouvent
facilement (si elles ont été bien préparées!)

exemple:
org: C:WINDOWSi386
déplacé E:BackUpWindowsI386
lien C:WINDOWSi386 pointant vers E:BackUpWindowsI386

Cette situation me permet de minimiser la partition OS et en facilite
les backups DriveImage. (moins gros)

Pouvez-vous me dire si ma méthode comporte un inconvénient?


Tu parles bien de "lien" (hardlink) n'est-ce pas ?
Obtenu par la fonction CREATEDIRECTORY et à la structure
FSCTL_SET_REPARSE_POINT ...
Que l'on trouve dans l'outil "JUNCTION" de Mark Russinovich
http://www.sysinternals.com/utilities/junction.html

Si c'est bien cela, pas de problème...


'hardlink' ? je ne connais pas. Je parle simplement de la fonction que l'on
trouve dans l'explorer de fichier, où il suffit de cliquer à droite et créer
un lien:
[pointer un répertoire] > [cliquer à droite] > nouveau > raccourci >
[chercher l'emplacement=E:BackUpWindowsI386] > suivant > [mettre le nom
du lien=i386] et voilà!

J'utilise couramment cette méthode pour me déplacer rapidement d'un
répertoire à un autre.

Par contre je n'arrive pas à me déplacer le long de ces liens quand je
programme en Delphi5. Le listage d'un répertoire, ne me permet pas de
retrouver un code de lien... Si vous avez une idée/solution pour me les
retrouver, je serais TRES intéressé. Cela doit être un code du style/famille
'readonly', hidden, dir, file,... mais je ne sais pas où trouver l'info!
(et pourtant j'ai beaucoup cherché... cela doit être trop gros pour le
voir!)

Merci pour ce dialogue

JMP


Avatar
Jean-Claude BELLAMY
Dans le message :453e0cb5$0$1812$,
K8lap a pris la peine d'écrire ce qui suit :
RE! comme dit si bien Guy Bedos... (dans le sens de re-bonjour)

Personnellement j'utilise la notion de lien (link). Je déplace le
répertoire i386 vers un autre disque dur/partition (réservé à des
fichiers rarement lus)
et je crée à la place du répertoire i386 d'origine un lien
répertoire pointant vers l'autre disque... Ce qui évite de passer
par la base de registre... (qui reste toujours pour moi un mystère)


Ce n'est rien d'autre qu'une (très) grosse base de données, ayant une
structure arborescente ...
Et très LOGIQUE !


Je n'ai rien contre cette structure de base de données, mais quand on
veut modifier/rechercher quelquechose, on est incapable de savoir
quoi et où chercher.


Avec un minimum d'esprit cartésien, on y arrive facilement !

Les infos sont éparpillées n'importe où
Meuhhhhhhhh non !!!!!


... il faut d'abord connaître les mots clés.
Dans l'exemple cité, comment deviner que le mot clé
ServicePackSourcePath existe?
Il suffit de faire une recherche sur "Servicepack" !!! (çà tu connais, non

?)
Et même si tu as des doutes entre "Servicepack" ou "Service pack" ou
"SrvPach", ou ...., il sufit d'effectuer une recherche sur le nom
(incomplet) du répertoire concerné ! (p.ex. "i386Serv")

J'ai TOUJOURS trouvé TOUT SEUL TOUTES les clefs avec cette méthode !
Un peu d'esprit logique + la fonction Rechercher !


Il faut d'abord avoir la connaissance
avant de trouver l'information! C'est une bonne méthode pour empêcher
les gens de comprendre les choses...
Cela me déroute beaucoup car ce n'est pas mon mode de pensée! Je
préfère de beaucoup la notion de fichier .ini, où les informations se
trouvent facilement (si elles ont été bien préparées!)
Oui ...et NON ..

Car le pb de fichiers INI, (tout comme sous Linux/UNIX les xxxx.conf ou les
conf.xxxx) c'est qu'il y en a plein, on ne sait pas où ils sont, et tout
d'abord s'ils existent, et s'ils existents, quels sont leurs noms,..
P.ex., avec des applis telles que MySQL+Apache+PHP, qui fonctionnent à coup
de .ini ou de .conf, c'est l'horreur à chaque fois pour les retrouver (sauf
si on y travaille en permanence)
MySQL
-> "my.ini" dans le dossier principal de l'appli
PHP
-> "php.ini" dans le dossier de WIndos
Apache
-> "httpd.conf" dans le sous dossier "conf" du
dossier principal de l'appli.

Alors que dans la BDR, on va dans HKLMSoftware, et on trouve !
Au début des OS Win32 je regrettais les fichiers .ini et trouvais la BDR un
peu merdique, mais avec l'inflation des logiciels, et ayant compris
l'organisaton de la BDR qui est très slogique (à part quelques exceptions,
comme partout), la BDR est beaucoup plus pratique.
PB : comme c'est monolithique, si les quelques fichiers (= ruches) de la BDR
sont flingués, on perd tout !
Donc comme partout, fiare des SAUVEGARDES !

exemple:
org: C:WINDOWSi386
déplacé E:BackUpWindowsI386
lien C:WINDOWSi386 pointant vers E:BackUpWindowsI386

Cette situation me permet de minimiser la partition OS et en
facilite les backups DriveImage. (moins gros)

Pouvez-vous me dire si ma méthode comporte un inconvénient?


Tu parles bien de "lien" (hardlink) n'est-ce pas ?
Obtenu par la fonction CREATEDIRECTORY et à la structure
FSCTL_SET_REPARSE_POINT ...
Que l'on trouve dans l'outil "JUNCTION" de Mark Russinovich
http://www.sysinternals.com/utilities/junction.html

Si c'est bien cela, pas de problème...


'hardlink' ? je ne connais pas. Je parle simplement de la fonction
que l'on trouve dans l'explorer de fichier, où il suffit de cliquer à
droite et créer un lien:
[pointer un répertoire] > [cliquer à droite] > nouveau > raccourci >
[chercher l'emplacement=E:BackUpWindowsI386] > suivant > [mettre
le nom du lien=i386] et voilà!


CE N'EST PAS UN LIEN !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
C'est un raccourci, et çà n'a RIEN à voir !

Donc je RETIRE mon appréciation "pas de problème"
Au contraire, ton système ne sert à RIEN !
Car si par hasard un composant du SP est détruit, le système ne pourra pas
le trouver dans le dossier C:WINDOWSi386 (la présence du raccourci lui
est totalement orthogonale !!!)

J'étais un peu et heureusement étonné que tu connaisses la notion de
"hardlink" (les UNIXIENS pratiquent cela assiduement !), car ce n'est pas
pour le commun des mortels..

Un lien symbolique (à ne pas confondre avec un raccourci) est un fichier
virtuel qui pointe vers un fichier réel. Il va apparaître dans un répertoire
cible, mais se limitera à une entrée dans le répertoire, et un lien
symbolique dans la MFT, faisant la liaison entre le fichier réel et
l'endroit où il apparaît virtuellement.

A l'opposé, un raccourci est un authentique fichier, bien réel, à extension
".lnk", qui contient des infos diverses qui seront interprétées par le shell
pour aller chercher le fichier d'origine.
Un inconvénient d'un raccourci est qu'il ne "passe" pas les réseaux (si on
monte un disque réseau, et que l'on clique sur un raccourci dans ce disque,
on aura des surprises, le shell allant chercher le fichier sur la machine
locale et non pas sur la machine distante). Il n'y a pas cet inconvénient
avec un "vrai lien symbolique", puisque dès qu'un veut y accéder, il y a
immédiatement un ré-aiguillage automatique vers le fichier d'origine.



J'utilise couramment cette méthode pour me déplacer rapidement d'un
répertoire à un autre.
Çà ne sert qu'à çà !


Par contre je n'arrive pas à me déplacer le long de ces liens quand je
programme en Delphi5.
Evidemment !

A moins de chercher l'existence du raccourci, puis lire son contenu, et agir
en conséquence !

Le listage d'un répertoire, ne me permet pas de
retrouver un code de lien...
PARFAITEMENT NORMAL !


Si vous avez une idée/solution pour me
les retrouver, je serais TRES intéressé. Cela doit être un code du
style/famille 'readonly', hidden, dir, file,...
Oh que non !!!!!

C'est bien plus complexe que çà ...

mais je ne sais pas
où trouver l'info! (et pourtant j'ai beaucoup cherché... cela doit
être trop gros pour le voir!)


Non, non, c'est assez subtil pour celui qui n'est pas spécialiste (et
visiblement, tu fais partie de cette catégorie! ;-))

C'est ce que je t'ai dit :
Il faut passer par les liens symboliques et les jonctions, qui sont des
fonctionnalités AVANCÉES des partitions NTFS (impossible sur une FAT)
J'y ai consacré un paragraphe sur mon site :
http://www.bellamyjc.org/fr/theoriemultiboot3.html#liens_symboliques

En ce qui concerne les point de jonctions, cf. ce très bon article (très)
technique:
http://www.codeproject.com/w2k/junctionpoints.asp

Et bien sur le site de Mark Russinovich.
http://www.sysinternals.com/utilities/junction.html

--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP]
http://www.bellamyjc.org ou http://jc.bellamy.free.fr



Avatar
K8lap
Bonjour et merci pour la réponse,

Personnellement j'utilise la notion de lien (link). Je déplace le
répertoire i386 vers un autre disque dur/partition (réservé à des
fichiers rarement lus)
et je crée à la place du répertoire i386 d'origine un lien
répertoire pointant vers l'autre disque... Ce qui évite de passer
par la base de registre... (qui reste toujours pour moi un mystère)


Ce n'est rien d'autre qu'une (très) grosse base de données, ayant une
structure arborescente ...
Et très LOGIQUE !


Je n'ai rien contre cette structure de base de données, mais quand on
veut modifier/rechercher quelquechose, on est incapable de savoir
quoi et où chercher.


Avec un minimum d'esprit cartésien, on y arrive facilement !


Il sera difficile de prouver que je n'ai pas un esprit cartésien...
et c'est probablement parce que j'ai beaucoup travaillé avec des américains,
que j'ai un doute concernant le leur. (et surtout dans leurs créations.) Bon
je ne cherche pas à lancer un débat.

Les infos sont éparpillées n'importe où
Meuhhhhhhhh non !!!!!



Hum... Bon le n'importe où est évidemment trop fort! il faut le prendre au
second degré.
Une recherche dans regedit de i386 déclenche bien une trentaine de réponse.
et pas les 2 parametres que vous avez cités.
(Je ne cherche pas à vous attaquer, ni à me justifier, simplement à
amméliorer ma connaissance)

... il faut d'abord connaître les mots clés.
Dans l'exemple cité, comment deviner que le mot clé
ServicePackSourcePath existe?
Il suffit de faire une recherche sur "Servicepack" !!! (çà tu connais, non

?)


Quelle drôle d'idée de prendre "Servicepack" pour un problème de i386!
Pourquoi pas SP, repair, tuning, install etc...
(PS Je ne suis pas un professionel de XP. et j'ai beaucoup d'autres points
d'intérêt que résoudre la stabilité de XP)
i386 était utilisé à l'origine pour faire des installations de NT. Pas pour
des services packs

Et même si tu as des doutes entre "Servicepack" ou "Service pack" ou
"SrvPach", ou ...., il sufit d'effectuer une recherche sur le nom
(incomplet) du répertoire concerné ! (p.ex. "i386Serv")

J'ai TOUJOURS trouvé TOUT SEUL TOUTES les clefs avec cette méthode !
Un peu d'esprit logique + la fonction Rechercher !


Ok pour la méthode, mais les effets de bord sont toujours à craindre. (et
quelquefois plusieurs semaines après)
Et puis quand vous regardez la registry, avec tout ces passages cryptés(?)
On se demande toujours ce que cela cache?

Il faut d'abord avoir la connaissance
avant de trouver l'information! C'est une bonne méthode pour empêcher
les gens de comprendre les choses...
Cela me déroute beaucoup car ce n'est pas mon mode de pensée! Je
préfère de beaucoup la notion de fichier .ini, où les informations se
trouvent facilement (si elles ont été bien préparées!)
Oui ...et NON ..

Car le pb de fichiers INI, (tout comme sous Linux/UNIX les xxxx.conf ou
les conf.xxxx) c'est qu'il y en a plein, on ne sait pas où ils sont,


Il suffit de les mettre là où est installée l'application, évidemment! et
ailleurs que dans l'OS.

et tout d'abord s'ils existent, et s'ils existents, quels sont leurs
noms,..
P.ex., avec des applis telles que MySQL+Apache+PHP, qui fonctionnent à
coup de .ini ou de .conf, c'est l'horreur à chaque fois pour les retrouver
(sauf si on y travaille en permanence)
MySQL
-> "my.ini" dans le dossier principal de l'appli
PHP
-> "php.ini" dans le dossier de WIndos
Apache
-> "httpd.conf" dans le sous dossier "conf" du
dossier principal de l'appli.

Alors que dans la BDR, on va dans HKLMSoftware, et on trouve !
Au début des OS Win32 je regrettais les fichiers .ini et trouvais la BDR
un peu merdique, mais avec l'inflation des logiciels, et ayant compris
l'organisaton de la BDR qui est très slogique (à part quelques exceptions,
comme partout), la BDR est beaucoup plus pratique.
PB : comme c'est monolithique, si les quelques fichiers (= ruches) de la
BDR sont flingués, on perd tout !
Donc comme partout, fiare des SAUVEGARDES !


C'est pas de l'unix/Linux ça?
(Moi je ne discute que XP. C'est mon seul domaine de connaissance en OS.
Tout du moins dans cette conversation)

exemple:
org: C:WINDOWSi386
déplacé E:BackUpWindowsI386
lien C:WINDOWSi386 pointant vers E:BackUpWindowsI386

Cette situation me permet de minimiser la partition OS et en
facilite les backups DriveImage. (moins gros)

Pouvez-vous me dire si ma méthode comporte un inconvénient?


Tu parles bien de "lien" (hardlink) n'est-ce pas ?
Obtenu par la fonction CREATEDIRECTORY et à la structure
FSCTL_SET_REPARSE_POINT ...
Que l'on trouve dans l'outil "JUNCTION" de Mark Russinovich
http://www.sysinternals.com/utilities/junction.html

Si c'est bien cela, pas de problème...


'hardlink' ? je ne connais pas. Je parle simplement de la fonction
que l'on trouve dans l'explorer de fichier, où il suffit de cliquer à
droite et créer un lien:
[pointer un répertoire] > [cliquer à droite] > nouveau > raccourci >
[chercher l'emplacement=E:BackUpWindowsI386] > suivant > [mettre
le nom du lien=i386] et voilà!


CE N'EST PAS UN LIEN !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
C'est un raccourci, et çà n'a RIEN à voir !


Les "raccourcis" en français, s'appellent liens en anglais (.lnk abréviation
de link)
Ce que vous semblez sous entendre c'est que les liens fait par Microsoft
sont buggés... (ce qui ne m'étonnerai qu'à moitié)

Donc je RETIRE mon appréciation "pas de problème"
Au contraire, ton système ne sert à RIEN !
Car si par hasard un composant du SP est détruit, le système ne pourra pas
le trouver dans le dossier C:WINDOWSi386 (la présence du raccourci lui
est totalement orthogonale !!!)


Joli, comme expresssion (dans le sens mathématique du terme j'espère)

Un programme qui appelle une donnée dans C:WINDOWSi386 doit la trouver
(après son voyage dans l'hyper espace du lien)


J'étais un peu et heureusement étonné que tu connaisses la notion de
"hardlink" (les UNIXIENS pratiquent cela assiduement !), car ce n'est pas
pour le commun des mortels..

Un lien symbolique (à ne pas confondre avec un raccourci) est un fichier
virtuel qui pointe vers un fichier réel. Il va apparaître dans un
répertoire cible, mais se limitera à une entrée dans le répertoire, et un
lien symbolique dans la MFT, faisant la liaison entre le fichier réel et
l'endroit où il apparaît virtuellement.


C'est bien ce sens que je donne à lien.
(très vieux souvenir d'Aegis)

A l'opposé, un raccourci est un authentique fichier, bien réel, à
extension ".lnk", qui contient des infos diverses qui seront interprétées
par le shell pour aller chercher le fichier d'origine.


Un inconvénient d'un raccourci est qu'il ne "passe" pas les réseaux (si on
monte un disque réseau, et que l'on clique sur un raccourci dans ce
disque, on aura des surprises, le shell allant chercher le fichier sur la
machine locale et non pas sur la machine distante). Il n'y a pas cet
inconvénient avec un "vrai lien symbolique", puisque dès qu'un veut y
accéder, il y a immédiatement un ré-aiguillage automatique vers le fichier
d'origine.


Il me semble pourtant avoir déjà utilisé ce genre de fonction. Il va
falloir que je vérifie cela.

J'utilise couramment cette méthode pour me déplacer rapidement d'un
répertoire à un autre.
Çà ne sert qu'à çà !


Par contre je n'arrive pas à me déplacer le long de ces liens quand je
programme en Delphi5.
Evidemment !

A moins de chercher l'existence du raccourci, puis lire son contenu, et
agir en conséquence !


On arrive pourtant à effectuer des traitements à travers un lien. (Il faut
quand même que je vérifie si cela passe bien par un lien, ou si l'info m'a
été fournie par l'OS à travers le lien)
(Mais pas à faire un changement de répertoire, si mes souvenirs sont bons.
C'est ce pb qui me préoccupe.
Mais il y a tellement d'autres possibilités de faire cela)

Le listage d'un répertoire, ne me permet pas de
retrouver un code de lien...
PARFAITEMENT NORMAL !


Si vous avez une idée/solution pour me
les retrouver, je serais TRES intéressé. Cela doit être un code du
style/famille 'readonly', hidden, dir, file,...
Oh que non !!!!!

C'est bien plus complexe que çà ...


Ne vous inquiétez pas pour la complexité. J'ai une piste.

mais je ne sais pas
où trouver l'info! (et pourtant j'ai beaucoup cherché... cela doit
être trop gros pour le voir!)



en effet c'était trop gros!

Non, non, c'est assez subtil pour celui qui n'est pas spécialiste (et
visiblement, tu fais partie de cette catégorie! ;-))


Je l'ai déjà dit, XP n'est pas mon métier. (ce n'est qu'un outil)

C'est ce que je t'ai dit :
Il faut passer par les liens symboliques et les jonctions, qui sont des
fonctionnalités AVANCÉES des partitions NTFS (impossible sur une FAT)
J'y ai consacré un paragraphe sur mon site :
http://www.bellamyjc.org/fr/theoriemultiboot3.html#liens_symboliques

En ce qui concerne les point de jonctions, cf. ce très bon article (très)
technique:
http://www.codeproject.com/w2k/junctionpoints.asp

Et bien sur le site de Mark Russinovich.
http://www.sysinternals.com/utilities/junction.html


Je note ces infos pour le jour où je modifierai un de mes programmes. Mais
pour l'instant, j'ai d'autres urgences.

En conclusion, je retiens que
- Microsoft ne fait pas de vrais liens (Ils sont nuls! ... sur ce sujet!
... et qqs autres...)
- que j'ai appris des choses, que j'en devine d'autres et que je vais
pouvoir continuer ma conquête de l'inutile.
- que j'ai une piste à débroussailler!
- que je ne vais pas pouvoir m'en occuper maintenant
- que cela faisait 6 mois que je n'avais discuté XP avec quelqu'un!
- qu'il est bientôt l'heure de manger!
- que je dois dire merci et au revoir!

JMP




Avatar
Laurent Gébeau [MToo]
Bonsoir

Sans base de registre, pas de profils utilisateurs, pas de stratégies ....

Pour commencez lisez toujours ça : http://www.toutwindows.com/registre.shtml
ça vous aidra.

Je partage l'avis de Jean Claude, quand on a compris le principe (ça prends
pas 10 minutes c'est sur) c'est relativment intuitif... même si il y a
souvent des inconsistences (souvent pour des raisons historiques).

Un outil très pratique de www.sysinternals.com : NTRegmon : pour visualiser
les clefs lues à un moment donné.

--
Laurent Gébeau (MToo)
[MVP Windows]

** http://www.toutwindows.com **
Tout sur Windows Server, Windows XP, Windows Vista, (FAQ XPSP2, FAQ AD et
FAQ UAC). Consultez mon blog : http://mtoo.spaces.live.com/

** http://www.mtoo.net **
Photos, météo, climato et conseils pour surfer sur le net. Nouvelles photos
toutes les semaines sur http://photomtoo.spaces.live.com




"K8lap" a écrit dans le message de news:
453f361e$0$12025$
Bonjour et merci pour la réponse,

Personnellement j'utilise la notion de lien (link). Je déplace le
répertoire i386 vers un autre disque dur/partition (réservé à des
fichiers rarement lus)
et je crée à la place du répertoire i386 d'origine un lien
répertoire pointant vers l'autre disque... Ce qui évite de passer
par la base de registre... (qui reste toujours pour moi un mystère)


Ce n'est rien d'autre qu'une (très) grosse base de données, ayant une
structure arborescente ...
Et très LOGIQUE !


Je n'ai rien contre cette structure de base de données, mais quand on
veut modifier/rechercher quelquechose, on est incapable de savoir
quoi et où chercher.


Avec un minimum d'esprit cartésien, on y arrive facilement !


Il sera difficile de prouver que je n'ai pas un esprit cartésien...
et c'est probablement parce que j'ai beaucoup travaillé avec des
américains, que j'ai un doute concernant le leur. (et surtout dans leurs
créations.) Bon je ne cherche pas à lancer un débat.

Les infos sont éparpillées n'importe où
Meuhhhhhhhh non !!!!!



Hum... Bon le n'importe où est évidemment trop fort! il faut le prendre au
second degré.
Une recherche dans regedit de i386 déclenche bien une trentaine de
réponse. et pas les 2 parametres que vous avez cités.
(Je ne cherche pas à vous attaquer, ni à me justifier, simplement à
amméliorer ma connaissance)

... il faut d'abord connaître les mots clés.
Dans l'exemple cité, comment deviner que le mot clé
ServicePackSourcePath existe?
Il suffit de faire une recherche sur "Servicepack" !!! (çà tu connais,

non ?)


Quelle drôle d'idée de prendre "Servicepack" pour un problème de i386!
Pourquoi pas SP, repair, tuning, install etc...
(PS Je ne suis pas un professionel de XP. et j'ai beaucoup d'autres points
d'intérêt que résoudre la stabilité de XP)
i386 était utilisé à l'origine pour faire des installations de NT. Pas
pour des services packs

Et même si tu as des doutes entre "Servicepack" ou "Service pack" ou
"SrvPach", ou ...., il sufit d'effectuer une recherche sur le nom
(incomplet) du répertoire concerné ! (p.ex. "i386Serv")

J'ai TOUJOURS trouvé TOUT SEUL TOUTES les clefs avec cette méthode !
Un peu d'esprit logique + la fonction Rechercher !


Ok pour la méthode, mais les effets de bord sont toujours à craindre. (et
quelquefois plusieurs semaines après)
Et puis quand vous regardez la registry, avec tout ces passages cryptés(?)
On se demande toujours ce que cela cache?

Il faut d'abord avoir la connaissance
avant de trouver l'information! C'est une bonne méthode pour empêcher
les gens de comprendre les choses...
Cela me déroute beaucoup car ce n'est pas mon mode de pensée! Je
préfère de beaucoup la notion de fichier .ini, où les informations se
trouvent facilement (si elles ont été bien préparées!)
Oui ...et NON ..

Car le pb de fichiers INI, (tout comme sous Linux/UNIX les xxxx.conf ou
les conf.xxxx) c'est qu'il y en a plein, on ne sait pas où ils sont,


Il suffit de les mettre là où est installée l'application, évidemment! et
ailleurs que dans l'OS.

et tout d'abord s'ils existent, et s'ils existents, quels sont leurs
noms,..
P.ex., avec des applis telles que MySQL+Apache+PHP, qui fonctionnent à
coup de .ini ou de .conf, c'est l'horreur à chaque fois pour les
retrouver (sauf si on y travaille en permanence)
MySQL
-> "my.ini" dans le dossier principal de l'appli
PHP
-> "php.ini" dans le dossier de WIndos
Apache
-> "httpd.conf" dans le sous dossier "conf" du
dossier principal de l'appli.

Alors que dans la BDR, on va dans HKLMSoftware, et on trouve !
Au début des OS Win32 je regrettais les fichiers .ini et trouvais la BDR
un peu merdique, mais avec l'inflation des logiciels, et ayant compris
l'organisaton de la BDR qui est très slogique (à part quelques
exceptions, comme partout), la BDR est beaucoup plus pratique.
PB : comme c'est monolithique, si les quelques fichiers (= ruches) de la
BDR sont flingués, on perd tout !
Donc comme partout, fiare des SAUVEGARDES !


C'est pas de l'unix/Linux ça?
(Moi je ne discute que XP. C'est mon seul domaine de connaissance en OS.
Tout du moins dans cette conversation)

exemple:
org: C:WINDOWSi386
déplacé E:BackUpWindowsI386
lien C:WINDOWSi386 pointant vers E:BackUpWindowsI386

Cette situation me permet de minimiser la partition OS et en
facilite les backups DriveImage. (moins gros)

Pouvez-vous me dire si ma méthode comporte un inconvénient?


Tu parles bien de "lien" (hardlink) n'est-ce pas ?
Obtenu par la fonction CREATEDIRECTORY et à la structure
FSCTL_SET_REPARSE_POINT ...
Que l'on trouve dans l'outil "JUNCTION" de Mark Russinovich
http://www.sysinternals.com/utilities/junction.html

Si c'est bien cela, pas de problème...


'hardlink' ? je ne connais pas. Je parle simplement de la fonction
que l'on trouve dans l'explorer de fichier, où il suffit de cliquer à
droite et créer un lien:
[pointer un répertoire] > [cliquer à droite] > nouveau > raccourci >
[chercher l'emplacement=E:BackUpWindowsI386] > suivant > [mettre
le nom du lien=i386] et voilà!


CE N'EST PAS UN LIEN !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
C'est un raccourci, et çà n'a RIEN à voir !


Les "raccourcis" en français, s'appellent liens en anglais (.lnk
abréviation de link)
Ce que vous semblez sous entendre c'est que les liens fait par Microsoft
sont buggés... (ce qui ne m'étonnerai qu'à moitié)

Donc je RETIRE mon appréciation "pas de problème"
Au contraire, ton système ne sert à RIEN !
Car si par hasard un composant du SP est détruit, le système ne pourra
pas le trouver dans le dossier C:WINDOWSi386 (la présence du raccourci
lui est totalement orthogonale !!!)


Joli, comme expresssion (dans le sens mathématique du terme j'espère)

Un programme qui appelle une donnée dans C:WINDOWSi386 doit la trouver
(après son voyage dans l'hyper espace du lien)


J'étais un peu et heureusement étonné que tu connaisses la notion de
"hardlink" (les UNIXIENS pratiquent cela assiduement !), car ce n'est pas
pour le commun des mortels..

Un lien symbolique (à ne pas confondre avec un raccourci) est un fichier
virtuel qui pointe vers un fichier réel. Il va apparaître dans un
répertoire cible, mais se limitera à une entrée dans le répertoire, et un
lien symbolique dans la MFT, faisant la liaison entre le fichier réel et
l'endroit où il apparaît virtuellement.


C'est bien ce sens que je donne à lien.
(très vieux souvenir d'Aegis)

A l'opposé, un raccourci est un authentique fichier, bien réel, à
extension ".lnk", qui contient des infos diverses qui seront interprétées
par le shell pour aller chercher le fichier d'origine.


Un inconvénient d'un raccourci est qu'il ne "passe" pas les réseaux (si
on monte un disque réseau, et que l'on clique sur un raccourci dans ce
disque, on aura des surprises, le shell allant chercher le fichier sur la
machine locale et non pas sur la machine distante). Il n'y a pas cet
inconvénient avec un "vrai lien symbolique", puisque dès qu'un veut y
accéder, il y a immédiatement un ré-aiguillage automatique vers le
fichier d'origine.


Il me semble pourtant avoir déjà utilisé ce genre de fonction. Il va
falloir que je vérifie cela.

J'utilise couramment cette méthode pour me déplacer rapidement d'un
répertoire à un autre.
Çà ne sert qu'à çà !


Par contre je n'arrive pas à me déplacer le long de ces liens quand je
programme en Delphi5.
Evidemment !

A moins de chercher l'existence du raccourci, puis lire son contenu, et
agir en conséquence !


On arrive pourtant à effectuer des traitements à travers un lien. (Il faut
quand même que je vérifie si cela passe bien par un lien, ou si l'info m'a
été fournie par l'OS à travers le lien)
(Mais pas à faire un changement de répertoire, si mes souvenirs sont bons.
C'est ce pb qui me préoccupe.
Mais il y a tellement d'autres possibilités de faire cela)

Le listage d'un répertoire, ne me permet pas de
retrouver un code de lien...
PARFAITEMENT NORMAL !


Si vous avez une idée/solution pour me
les retrouver, je serais TRES intéressé. Cela doit être un code du
style/famille 'readonly', hidden, dir, file,...
Oh que non !!!!!

C'est bien plus complexe que çà ...


Ne vous inquiétez pas pour la complexité. J'ai une piste.

mais je ne sais pas
où trouver l'info! (et pourtant j'ai beaucoup cherché... cela doit
être trop gros pour le voir!)



en effet c'était trop gros!

Non, non, c'est assez subtil pour celui qui n'est pas spécialiste (et
visiblement, tu fais partie de cette catégorie! ;-))


Je l'ai déjà dit, XP n'est pas mon métier. (ce n'est qu'un outil)

C'est ce que je t'ai dit :
Il faut passer par les liens symboliques et les jonctions, qui sont des
fonctionnalités AVANCÉES des partitions NTFS (impossible sur une FAT)
J'y ai consacré un paragraphe sur mon site :
http://www.bellamyjc.org/fr/theoriemultiboot3.html#liens_symboliques

En ce qui concerne les point de jonctions, cf. ce très bon article (très)
technique:
http://www.codeproject.com/w2k/junctionpoints.asp

Et bien sur le site de Mark Russinovich.
http://www.sysinternals.com/utilities/junction.html


Je note ces infos pour le jour où je modifierai un de mes programmes. Mais
pour l'instant, j'ai d'autres urgences.

En conclusion, je retiens que
- Microsoft ne fait pas de vrais liens (Ils sont nuls! ... sur ce sujet!
... et qqs autres...)
- que j'ai appris des choses, que j'en devine d'autres et que je vais
pouvoir continuer ma conquête de l'inutile.
- que j'ai une piste à débroussailler!
- que je ne vais pas pouvoir m'en occuper maintenant
- que cela faisait 6 mois que je n'avais discuté XP avec quelqu'un!
- qu'il est bientôt l'heure de manger!
- que je dois dire merci et au revoir!

JMP







1 2