[INFO]A propos du dossier $hf_mig$ : Comment le déplacer ...
24 réponses
Jean-Claude BELLAMY
Hello happy Taxpayers !
Tous (ou presque!) les utilisateurs de XP et W2K3 (et SBS, WHS ...)
connaissent les dossiers "$NtUninstall....$" et "$hf_mig$", situés dans le
dossier %windir% (en règle générale "c:\windows")
Ils sont créés ou "alimentés" par tous les correctifs de Windows.
Les dossiers "$NtUninstall....$", qui contiennent les fichiers nécessaires à
la DÉSINSTALLATION de ces correctifs, PEUVENT être SUPPRIMÉS si on a décidé
définitivement de ne pas les désinstaller (ce qui se pratique toujours, sauf
bug notoire dans un correctif).
J'ai d'ailleurs écrit un script qui fait proprement et automatiquement cette
opération de suppression
(http://www.bellamyjc.org/fr/windows2000.html#Ntuninstall)
PAR CONTRE, le dossier "$hf_mig$" contient un ensemble de sous-dossiers
(ayant pour noms respectifs les articles associés de la base de
connaissances, p.ex. "KB941202") lesquels contiennent des copies des DLL (et
.SYS, .OCX, ...) MISES A JOUR par ces correctifs.
Le dossier "$hf_mig$" a donc pour rôle pour maintenir la cohérence dans les
dernières versions de DLL (au cas où l'installation d'un logiciel viendrait
à en remplacer), si bien qu'il NE FAUT PAS SUPPRIMER ce dossier !
NB: sa suppression ne se traduira par aucun message d'erreur, par contre on
risque de découvrir peu à peu des incohérences et dysfonctionnements
inexpliqués du système.
Cette interdiction de le supprimer est particulièrement GÊNANTE, car la
taille globale de ce dossier devient très importante (environ 300 Mo
actuellement)
Or il peut arriver que la partition du système soit saturée ...
Et l'emplacement de ce dossier est "en dur" (il doit obligatoirement être
dans %windir%)
Le problème semble donc insoluble, et pourtant ... :-)
... j'ai eu l'idée toute bête de faire appel aux "JONCTIONS" des partitions
NTFS, :
- en déplaçant "$hf_mig$" sur une autre partition (NTFS)
- en créant une JUNCTION de ce dossier à son
nouvel emplacement dans %windir% !
(à l'aide de l'outil de SysInternals)
Je décris la manip ici :
http://www.bellamyjc.org/fr/windowsxp2003.html#hf_mig
Et ainsi la morale est sauve ...
- $hf_mig$ ne prend plus de place dans %SystemDrive%
(la partition du système)
- $hf_mig$ est toujours disponible dans %windir% !
Et vive NTFS et Mark Russinovich ! ;-)
PS : cette méthode de transfert de dossiers volumineux + création de
JUNCTION peut être utilisée également pour plein d'autres applications
(p.ex. MSDN et son "méga" dossier "Microsoft Help" de plus de 450 Mo) sans
pour autant devoir bidouiller dans la BDR ou quoi que ce soit d'autre.
--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org
Dans le principe, ca correspond aux liens symboliques Linux ?
-- DR
Jean-Claude BELLAMY
"Droopy191" a écrit dans le message de news:471ccad5$0$12196$
Bonjour,
Dans le principe, ca correspond aux liens symboliques Linux ?
OUI, çà date de NTFS version de 3.0, apparu avec Windows 2000. Donc ce n'est pas spécialement nouveau. Et les applications de cette fonctionnalité étaient relativement rares jusqu'à présent. (Dans Linux, cette "redirection" de répertoires est très courante, p.ex. tout de qui est "X11")
Mais face aux correctifs de plus en plus fréquents et volumineux de XP et W2K3, des dossiers tels que $hf_mig$ ont "explosé", ce qui occasionne des problèmes chez certains utilisateurs (j'en fait partie !!!), qui se retrouvent avec une partition système trop petite et impossible à redimensionner pour "x" raisons (j'ai encore eu un courrier perso aujourd'hui à ce sujet).
Donc cette variante de "liens symboliques" tombe pile-poil pour résoudre le pb. Çà n'a rien de génial, mais c'est comme l'oeuf de Christophe Colomb, il suffisait d'y penser ! ;-)
-- May the Force be with You! La Connaissance s'accroît quand on la partage ---------------------------------------------------------- Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org
"Droopy191" <droopy191_pas_de_spam@free.fr> a écrit dans le message de
news:471ccad5$0$12196$426a34cc@news.free.fr...
Bonjour,
Dans le principe, ca correspond aux liens symboliques Linux ?
OUI, çà date de NTFS version de 3.0, apparu avec Windows 2000.
Donc ce n'est pas spécialement nouveau.
Et les applications de cette fonctionnalité étaient relativement rares
jusqu'à présent.
(Dans Linux, cette "redirection" de répertoires est très courante, p.ex.
tout de qui est "X11")
Mais face aux correctifs de plus en plus fréquents et volumineux de XP et
W2K3, des dossiers tels que $hf_mig$ ont "explosé", ce qui occasionne des
problèmes chez certains utilisateurs (j'en fait partie !!!), qui se
retrouvent avec une partition système trop petite et impossible à
redimensionner pour "x" raisons (j'ai encore eu un courrier perso
aujourd'hui à ce sujet).
Donc cette variante de "liens symboliques" tombe pile-poil pour résoudre le
pb.
Çà n'a rien de génial, mais c'est comme l'oeuf de Christophe Colomb, il
suffisait d'y penser ! ;-)
--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org
"Droopy191" a écrit dans le message de news:471ccad5$0$12196$
Bonjour,
Dans le principe, ca correspond aux liens symboliques Linux ?
OUI, çà date de NTFS version de 3.0, apparu avec Windows 2000. Donc ce n'est pas spécialement nouveau. Et les applications de cette fonctionnalité étaient relativement rares jusqu'à présent. (Dans Linux, cette "redirection" de répertoires est très courante, p.ex. tout de qui est "X11")
Mais face aux correctifs de plus en plus fréquents et volumineux de XP et W2K3, des dossiers tels que $hf_mig$ ont "explosé", ce qui occasionne des problèmes chez certains utilisateurs (j'en fait partie !!!), qui se retrouvent avec une partition système trop petite et impossible à redimensionner pour "x" raisons (j'ai encore eu un courrier perso aujourd'hui à ce sujet).
Donc cette variante de "liens symboliques" tombe pile-poil pour résoudre le pb. Çà n'a rien de génial, mais c'est comme l'oeuf de Christophe Colomb, il suffisait d'y penser ! ;-)
-- May the Force be with You! La Connaissance s'accroît quand on la partage ---------------------------------------------------------- Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org
Pépé le Pew
"Jean-Claude BELLAMY" a écrit dans le message de news:
... j'ai eu l'idée toute bête de faire appel aux "JONCTIONS" des partitions
bête mais géniale ...
You know what ... I'm happy
"Jean-Claude BELLAMY" <Jean-Claude.Bellamy@wanadoo.fr> a écrit dans le
message de news: 95726F09-97AC-4B7C-B365-A776B12B87FB@microsoft.com...
... j'ai eu l'idée toute bête de faire appel aux "JONCTIONS" des
partitions
"Jean-Claude BELLAMY" a écrit dans le message de news:
... j'ai eu l'idée toute bête de faire appel aux "JONCTIONS" des partitions
bête mais géniale ...
You know what ... I'm happy
Droopy191
"Droopy191" a écrit dans le message de news:471ccad5$0$12196$
Bonjour,
Dans le principe, ca correspond aux liens symboliques Linux ?
OUI, çà date de NTFS version de 3.0, apparu avec Windows 2000. Donc ce n'est pas spécialement nouveau. Et les applications de cette fonctionnalité étaient relativement rares jusqu'à présent.
C'est pourtant tès pratique. Je le voix bien pour faire un répertoire "multimedia" dans "mes documents" tout en ayant les données réparties sur différents disques ( par ex, un lien mp3s, un lien video...) .
Est ce que ca pourrait répondre au besoin de déplacer le doc & settings sur un autre disque ? ( en le faisant à partir de la cdr par exemple )
Merci pour cette astuce.
-- DR
"Droopy191" <droopy191_pas_de_spam@free.fr> a écrit dans le message de
news:471ccad5$0$12196$426a34cc@news.free.fr...
Bonjour,
Dans le principe, ca correspond aux liens symboliques Linux ?
OUI, çà date de NTFS version de 3.0, apparu avec Windows 2000.
Donc ce n'est pas spécialement nouveau.
Et les applications de cette fonctionnalité étaient relativement rares
jusqu'à présent.
C'est pourtant tès pratique. Je le voix bien pour faire un répertoire
"multimedia" dans "mes documents" tout en ayant les données réparties
sur différents disques ( par ex, un lien mp3s, un lien video...) .
Est ce que ca pourrait répondre au besoin de déplacer le doc & settings
sur un autre disque ? ( en le faisant à partir de la cdr par exemple )
"Droopy191" a écrit dans le message de news:471ccad5$0$12196$
Bonjour,
Dans le principe, ca correspond aux liens symboliques Linux ?
OUI, çà date de NTFS version de 3.0, apparu avec Windows 2000. Donc ce n'est pas spécialement nouveau. Et les applications de cette fonctionnalité étaient relativement rares jusqu'à présent.
C'est pourtant tès pratique. Je le voix bien pour faire un répertoire "multimedia" dans "mes documents" tout en ayant les données réparties sur différents disques ( par ex, un lien mp3s, un lien video...) .
Est ce que ca pourrait répondre au besoin de déplacer le doc & settings sur un autre disque ? ( en le faisant à partir de la cdr par exemple )
Merci pour cette astuce.
-- DR
Gilbert_13MRS
Bonsoir,
génial la manip !
J'utilise déjà ton delunistall qui fait merveille. Avec presque une centaine de patches je gagne quelques 450MB en FAT32.
Je reste en fat32 pour pouvoir utiliser un vieux ghost sur disquette. En plus j'ai peur des métadonnées dont j'ignore tout.
Dans ton cas de figure en NTFS, est-ce que windowsupdate retrouve sa route ?
Merci.
"Jean-Claude BELLAMY" wrote:
Hello happy Taxpayers !
Tous (ou presque!) les utilisateurs de XP et W2K3 (et SBS, WHS ...) connaissent les dossiers "$NtUninstall....$" et "$hf_mig$", situés dans le dossier %windir% (en règle générale "c:windows") Ils sont créés ou "alimentés" par tous les correctifs de Windows.
Les dossiers "$NtUninstall....$", qui contiennent les fichiers nécessaires à la DÉSINSTALLATION de ces correctifs, PEUVENT être SUPPRIMÉS si on a décidé définitivement de ne pas les désinstaller (ce qui se pratique toujours, sauf bug notoire dans un correctif). J'ai d'ailleurs écrit un script qui fait proprement et automatiquement cette opération de suppression (http://www.bellamyjc.org/fr/windows2000.html#Ntuninstall)
PAR CONTRE, le dossier "$hf_mig$" contient un ensemble de sous-dossiers (ayant pour noms respectifs les articles associés de la base de connaissances, p.ex. "KB941202") lesquels contiennent des copies des DLL (et ..SYS, .OCX, ...) MISES A JOUR par ces correctifs.
Le dossier "$hf_mig$" a donc pour rôle pour maintenir la cohérence dans les dernières versions de DLL (au cas où l'installation d'un logiciel viendrait à en remplacer), si bien qu'il NE FAUT PAS SUPPRIMER ce dossier ! NB: sa suppression ne se traduira par aucun message d'erreur, par contre on risque de découvrir peu à peu des incohérences et dysfonctionnements inexpliqués du système.
Cette interdiction de le supprimer est particulièrement GÊNANTE, car la taille globale de ce dossier devient très importante (environ 300 Mo actuellement) Or il peut arriver que la partition du système soit saturée ...
Et l'emplacement de ce dossier est "en dur" (il doit obligatoirement être dans %windir%) Le problème semble donc insoluble, et pourtant ... :-)
.... j'ai eu l'idée toute bête de faire appel aux "JONCTIONS" des partitions NTFS, : - en déplaçant "$hf_mig$" sur une autre partition (NTFS) - en créant une JUNCTION de ce dossier à son nouvel emplacement dans %windir% ! (à l'aide de l'outil de SysInternals)
Je décris la manip ici : http://www.bellamyjc.org/fr/windowsxp2003.html#hf_mig
Et ainsi la morale est sauve ... - $hf_mig$ ne prend plus de place dans %SystemDrive% (la partition du système) - $hf_mig$ est toujours disponible dans %windir% !
Et vive NTFS et Mark Russinovich ! ;-)
PS : cette méthode de transfert de dossiers volumineux + création de JUNCTION peut être utilisée également pour plein d'autres applications (p.ex. MSDN et son "méga" dossier "Microsoft Help" de plus de 450 Mo) sans pour autant devoir bidouiller dans la BDR ou quoi que ce soit d'autre.
-- May the Force be with You! La Connaissance s'accroît quand on la partage ---------------------------------------------------------- Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org
Bonsoir,
génial la manip !
J'utilise déjà ton delunistall qui fait merveille. Avec presque une centaine
de patches je gagne quelques 450MB en FAT32.
Je reste en fat32 pour pouvoir utiliser un vieux ghost sur disquette. En
plus j'ai peur des métadonnées dont j'ignore tout.
Dans ton cas de figure en NTFS, est-ce que windowsupdate retrouve sa route ?
Merci.
"Jean-Claude BELLAMY" wrote:
Hello happy Taxpayers !
Tous (ou presque!) les utilisateurs de XP et W2K3 (et SBS, WHS ...)
connaissent les dossiers "$NtUninstall....$" et "$hf_mig$", situés dans le
dossier %windir% (en règle générale "c:windows")
Ils sont créés ou "alimentés" par tous les correctifs de Windows.
Les dossiers "$NtUninstall....$", qui contiennent les fichiers nécessaires à
la DÉSINSTALLATION de ces correctifs, PEUVENT être SUPPRIMÉS si on a décidé
définitivement de ne pas les désinstaller (ce qui se pratique toujours, sauf
bug notoire dans un correctif).
J'ai d'ailleurs écrit un script qui fait proprement et automatiquement cette
opération de suppression
(http://www.bellamyjc.org/fr/windows2000.html#Ntuninstall)
PAR CONTRE, le dossier "$hf_mig$" contient un ensemble de sous-dossiers
(ayant pour noms respectifs les articles associés de la base de
connaissances, p.ex. "KB941202") lesquels contiennent des copies des DLL (et
..SYS, .OCX, ...) MISES A JOUR par ces correctifs.
Le dossier "$hf_mig$" a donc pour rôle pour maintenir la cohérence dans les
dernières versions de DLL (au cas où l'installation d'un logiciel viendrait
à en remplacer), si bien qu'il NE FAUT PAS SUPPRIMER ce dossier !
NB: sa suppression ne se traduira par aucun message d'erreur, par contre on
risque de découvrir peu à peu des incohérences et dysfonctionnements
inexpliqués du système.
Cette interdiction de le supprimer est particulièrement GÊNANTE, car la
taille globale de ce dossier devient très importante (environ 300 Mo
actuellement)
Or il peut arriver que la partition du système soit saturée ...
Et l'emplacement de ce dossier est "en dur" (il doit obligatoirement être
dans %windir%)
Le problème semble donc insoluble, et pourtant ... :-)
.... j'ai eu l'idée toute bête de faire appel aux "JONCTIONS" des partitions
NTFS, :
- en déplaçant "$hf_mig$" sur une autre partition (NTFS)
- en créant une JUNCTION de ce dossier à son
nouvel emplacement dans %windir% !
(à l'aide de l'outil de SysInternals)
Je décris la manip ici :
http://www.bellamyjc.org/fr/windowsxp2003.html#hf_mig
Et ainsi la morale est sauve ...
- $hf_mig$ ne prend plus de place dans %SystemDrive%
(la partition du système)
- $hf_mig$ est toujours disponible dans %windir% !
Et vive NTFS et Mark Russinovich ! ;-)
PS : cette méthode de transfert de dossiers volumineux + création de
JUNCTION peut être utilisée également pour plein d'autres applications
(p.ex. MSDN et son "méga" dossier "Microsoft Help" de plus de 450 Mo) sans
pour autant devoir bidouiller dans la BDR ou quoi que ce soit d'autre.
--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org
J'utilise déjà ton delunistall qui fait merveille. Avec presque une centaine de patches je gagne quelques 450MB en FAT32.
Je reste en fat32 pour pouvoir utiliser un vieux ghost sur disquette. En plus j'ai peur des métadonnées dont j'ignore tout.
Dans ton cas de figure en NTFS, est-ce que windowsupdate retrouve sa route ?
Merci.
"Jean-Claude BELLAMY" wrote:
Hello happy Taxpayers !
Tous (ou presque!) les utilisateurs de XP et W2K3 (et SBS, WHS ...) connaissent les dossiers "$NtUninstall....$" et "$hf_mig$", situés dans le dossier %windir% (en règle générale "c:windows") Ils sont créés ou "alimentés" par tous les correctifs de Windows.
Les dossiers "$NtUninstall....$", qui contiennent les fichiers nécessaires à la DÉSINSTALLATION de ces correctifs, PEUVENT être SUPPRIMÉS si on a décidé définitivement de ne pas les désinstaller (ce qui se pratique toujours, sauf bug notoire dans un correctif). J'ai d'ailleurs écrit un script qui fait proprement et automatiquement cette opération de suppression (http://www.bellamyjc.org/fr/windows2000.html#Ntuninstall)
PAR CONTRE, le dossier "$hf_mig$" contient un ensemble de sous-dossiers (ayant pour noms respectifs les articles associés de la base de connaissances, p.ex. "KB941202") lesquels contiennent des copies des DLL (et ..SYS, .OCX, ...) MISES A JOUR par ces correctifs.
Le dossier "$hf_mig$" a donc pour rôle pour maintenir la cohérence dans les dernières versions de DLL (au cas où l'installation d'un logiciel viendrait à en remplacer), si bien qu'il NE FAUT PAS SUPPRIMER ce dossier ! NB: sa suppression ne se traduira par aucun message d'erreur, par contre on risque de découvrir peu à peu des incohérences et dysfonctionnements inexpliqués du système.
Cette interdiction de le supprimer est particulièrement GÊNANTE, car la taille globale de ce dossier devient très importante (environ 300 Mo actuellement) Or il peut arriver que la partition du système soit saturée ...
Et l'emplacement de ce dossier est "en dur" (il doit obligatoirement être dans %windir%) Le problème semble donc insoluble, et pourtant ... :-)
.... j'ai eu l'idée toute bête de faire appel aux "JONCTIONS" des partitions NTFS, : - en déplaçant "$hf_mig$" sur une autre partition (NTFS) - en créant une JUNCTION de ce dossier à son nouvel emplacement dans %windir% ! (à l'aide de l'outil de SysInternals)
Je décris la manip ici : http://www.bellamyjc.org/fr/windowsxp2003.html#hf_mig
Et ainsi la morale est sauve ... - $hf_mig$ ne prend plus de place dans %SystemDrive% (la partition du système) - $hf_mig$ est toujours disponible dans %windir% !
Et vive NTFS et Mark Russinovich ! ;-)
PS : cette méthode de transfert de dossiers volumineux + création de JUNCTION peut être utilisée également pour plein d'autres applications (p.ex. MSDN et son "méga" dossier "Microsoft Help" de plus de 450 Mo) sans pour autant devoir bidouiller dans la BDR ou quoi que ce soit d'autre.
-- May the Force be with You! La Connaissance s'accroît quand on la partage ---------------------------------------------------------- Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org
lefrob
"Jean-Claude BELLAMY" a écrit dans le message de news:
Hello happy Taxpayers !
Tous (ou presque!) les utilisateurs de XP et W2K3 (et SBS, WHS ...) connaissent les dossiers "$NtUninstall....$" et "$hf_mig$", situés dans le dossier %windir% (en règle générale "c:windows") Ils sont créés ou "alimentés" par tous les correctifs de Windows.
Les dossiers "$NtUninstall....$", qui contiennent les fichiers nécessaires à la DÉSINSTALLATION de ces correctifs, PEUVENT être SUPPRIMÉS si on a décidé définitivement de ne pas les désinstaller (ce qui se pratique toujours, sauf bug notoire dans un correctif). J'ai d'ailleurs écrit un script qui fait proprement et automatiquement cette opération de suppression (http://www.bellamyjc.org/fr/windows2000.html#Ntuninstall)
PAR CONTRE, le dossier "$hf_mig$" contient un ensemble de sous-dossiers (ayant pour noms respectifs les articles associés de la base de connaissances, p.ex. "KB941202") lesquels contiennent des copies des DLL (et .SYS, .OCX, ...) MISES A JOUR par ces correctifs.
Le dossier "$hf_mig$" a donc pour rôle pour maintenir la cohérence dans les dernières versions de DLL (au cas où l'installation d'un logiciel viendrait à en remplacer), si bien qu'il NE FAUT PAS SUPPRIMER ce dossier ! NB: sa suppression ne se traduira par aucun message d'erreur, par contre on risque de découvrir peu à peu des incohérences et dysfonctionnements inexpliqués du système.
... j'ai eu l'idée toute bête de faire appel aux "JONCTIONS" des partitions NTFS, : Je décris la manip ici : http://www.bellamyjc.org/fr/windowsxp2003.html#hf_mig
Idée GENIALE (une de plus à ton actif ! )
Et ainsi la morale est sauve ... - $hf_mig$ ne prend plus de place dans %SystemDrive% (la partition du système) - $hf_mig$ est toujours disponible dans %windir% !
Et vive NTFS et Mark Russinovich ! ;-)
ET vive Jean-Claude BELAMY !
-- May the Force be with You!
La Connaissance s'accroît quand on la partage ---------------------------------------------------------- Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org
"Jean-Claude BELLAMY" <Jean-Claude.Bellamy@wanadoo.fr> a écrit dans le message de news:
95726F09-97AC-4B7C-B365-A776B12B87FB@microsoft.com...
Hello happy Taxpayers !
Tous (ou presque!) les utilisateurs de XP et W2K3 (et SBS, WHS ...) connaissent les dossiers "$NtUninstall....$" et "$hf_mig$",
situés dans le dossier %windir% (en règle générale "c:windows")
Ils sont créés ou "alimentés" par tous les correctifs de Windows.
Les dossiers "$NtUninstall....$", qui contiennent les fichiers nécessaires à la DÉSINSTALLATION de ces correctifs, PEUVENT être
SUPPRIMÉS si on a décidé définitivement de ne pas les désinstaller (ce qui se pratique toujours, sauf bug notoire dans un
correctif).
J'ai d'ailleurs écrit un script qui fait proprement et automatiquement cette opération de suppression
(http://www.bellamyjc.org/fr/windows2000.html#Ntuninstall)
PAR CONTRE, le dossier "$hf_mig$" contient un ensemble de sous-dossiers (ayant pour noms respectifs les articles associés de la
base de connaissances, p.ex. "KB941202") lesquels contiennent des copies des DLL (et .SYS, .OCX, ...) MISES A JOUR par ces
correctifs.
Le dossier "$hf_mig$" a donc pour rôle pour maintenir la cohérence dans les dernières versions de DLL (au cas où l'installation
d'un logiciel viendrait à en remplacer), si bien qu'il NE FAUT PAS SUPPRIMER ce dossier !
NB: sa suppression ne se traduira par aucun message d'erreur, par contre on risque de découvrir peu à peu des incohérences et
dysfonctionnements inexpliqués du système.
... j'ai eu l'idée toute bête de faire appel aux "JONCTIONS" des partitions NTFS, :
Je décris la manip ici :
http://www.bellamyjc.org/fr/windowsxp2003.html#hf_mig
Idée GENIALE (une de plus à ton actif ! )
Et ainsi la morale est sauve ...
- $hf_mig$ ne prend plus de place dans %SystemDrive%
(la partition du système)
- $hf_mig$ est toujours disponible dans %windir% !
Et vive NTFS et Mark Russinovich ! ;-)
ET vive Jean-Claude BELAMY !
--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org
"Jean-Claude BELLAMY" a écrit dans le message de news:
Hello happy Taxpayers !
Tous (ou presque!) les utilisateurs de XP et W2K3 (et SBS, WHS ...) connaissent les dossiers "$NtUninstall....$" et "$hf_mig$", situés dans le dossier %windir% (en règle générale "c:windows") Ils sont créés ou "alimentés" par tous les correctifs de Windows.
Les dossiers "$NtUninstall....$", qui contiennent les fichiers nécessaires à la DÉSINSTALLATION de ces correctifs, PEUVENT être SUPPRIMÉS si on a décidé définitivement de ne pas les désinstaller (ce qui se pratique toujours, sauf bug notoire dans un correctif). J'ai d'ailleurs écrit un script qui fait proprement et automatiquement cette opération de suppression (http://www.bellamyjc.org/fr/windows2000.html#Ntuninstall)
PAR CONTRE, le dossier "$hf_mig$" contient un ensemble de sous-dossiers (ayant pour noms respectifs les articles associés de la base de connaissances, p.ex. "KB941202") lesquels contiennent des copies des DLL (et .SYS, .OCX, ...) MISES A JOUR par ces correctifs.
Le dossier "$hf_mig$" a donc pour rôle pour maintenir la cohérence dans les dernières versions de DLL (au cas où l'installation d'un logiciel viendrait à en remplacer), si bien qu'il NE FAUT PAS SUPPRIMER ce dossier ! NB: sa suppression ne se traduira par aucun message d'erreur, par contre on risque de découvrir peu à peu des incohérences et dysfonctionnements inexpliqués du système.
... j'ai eu l'idée toute bête de faire appel aux "JONCTIONS" des partitions NTFS, : Je décris la manip ici : http://www.bellamyjc.org/fr/windowsxp2003.html#hf_mig
Idée GENIALE (une de plus à ton actif ! )
Et ainsi la morale est sauve ... - $hf_mig$ ne prend plus de place dans %SystemDrive% (la partition du système) - $hf_mig$ est toujours disponible dans %windir% !
Et vive NTFS et Mark Russinovich ! ;-)
ET vive Jean-Claude BELAMY !
-- May the Force be with You!
La Connaissance s'accroît quand on la partage ---------------------------------------------------------- Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org
Jean-Claude BELLAMY
"Gilbert_13MRS" a écrit dans le message de news:
Bonsoir,
génial la manip !
J'utilise déjà ton delunistall qui fait merveille. Avec presque une centaine de patches je gagne quelques 450MB en FAT32.
Je reste en fat32 pour pouvoir utiliser un vieux ghost sur disquette. En plus j'ai peur des métadonnées dont j'ignore tout.
Dans ton cas de figure en NTFS, est-ce que windowsupdate retrouve sa route ?
OUI (j'ai testé!) Windowsupdate installe les "$NTuninstall..." dans %windir% , puis les "KB...." dans %windir%$hf_mig$ , donc que ce soit une jonction ou un vrai répertoire, il n'en a rien à faire, c'est transparent pour lui, ce qui compte c'est que le chemin "%windir%$hf_mig$" existe !
-- May the Force be with You! La Connaissance s'accroît quand on la partage ---------------------------------------------------------- Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org
"Gilbert_13MRS" <Gilbert13MRS@discussions.microsoft.com> a écrit dans le
message de news:050498B4-08C2-4597-9251-935D2BCCD3EB@microsoft.com...
Bonsoir,
génial la manip !
J'utilise déjà ton delunistall qui fait merveille. Avec presque une
centaine
de patches je gagne quelques 450MB en FAT32.
Je reste en fat32 pour pouvoir utiliser un vieux ghost sur disquette. En
plus j'ai peur des métadonnées dont j'ignore tout.
Dans ton cas de figure en NTFS, est-ce que windowsupdate retrouve sa route
?
OUI (j'ai testé!)
Windowsupdate installe les "$NTuninstall..." dans %windir% , puis les
"KB...." dans %windir%$hf_mig$ , donc que ce soit une jonction ou un vrai
répertoire, il n'en a rien à faire, c'est transparent pour lui, ce qui
compte c'est que le chemin "%windir%$hf_mig$" existe !
--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org
J'utilise déjà ton delunistall qui fait merveille. Avec presque une centaine de patches je gagne quelques 450MB en FAT32.
Je reste en fat32 pour pouvoir utiliser un vieux ghost sur disquette. En plus j'ai peur des métadonnées dont j'ignore tout.
Dans ton cas de figure en NTFS, est-ce que windowsupdate retrouve sa route ?
OUI (j'ai testé!) Windowsupdate installe les "$NTuninstall..." dans %windir% , puis les "KB...." dans %windir%$hf_mig$ , donc que ce soit une jonction ou un vrai répertoire, il n'en a rien à faire, c'est transparent pour lui, ce qui compte c'est que le chemin "%windir%$hf_mig$" existe !
-- May the Force be with You! La Connaissance s'accroît quand on la partage ---------------------------------------------------------- Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org
Gilbert_13MRS
Bonjour,
et deluninstall ? Trouve-t-il aussi son chemin ?
Merci.
"Jean-Claude BELLAMY" wrote:
"Gilbert_13MRS" a écrit dans le message de news:
Bonsoir,
génial la manip !
J'utilise déjà ton delunistall qui fait merveille. Avec presque une centaine de patches je gagne quelques 450MB en FAT32.
Je reste en fat32 pour pouvoir utiliser un vieux ghost sur disquette. En plus j'ai peur des métadonnées dont j'ignore tout.
Dans ton cas de figure en NTFS, est-ce que windowsupdate retrouve sa route ?
OUI (j'ai testé!) Windowsupdate installe les "$NTuninstall..." dans %windir% , puis les "KB...." dans %windir%$hf_mig$ , donc que ce soit une jonction ou un vrai répertoire, il n'en a rien à faire, c'est transparent pour lui, ce qui compte c'est que le chemin "%windir%$hf_mig$" existe !
-- May the Force be with You! La Connaissance s'accroît quand on la partage ---------------------------------------------------------- Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org
Bonjour,
et deluninstall ? Trouve-t-il aussi son chemin ?
Merci.
"Jean-Claude BELLAMY" wrote:
"Gilbert_13MRS" <Gilbert13MRS@discussions.microsoft.com> a écrit dans le
message de news:050498B4-08C2-4597-9251-935D2BCCD3EB@microsoft.com...
Bonsoir,
génial la manip !
J'utilise déjà ton delunistall qui fait merveille. Avec presque une
centaine
de patches je gagne quelques 450MB en FAT32.
Je reste en fat32 pour pouvoir utiliser un vieux ghost sur disquette. En
plus j'ai peur des métadonnées dont j'ignore tout.
Dans ton cas de figure en NTFS, est-ce que windowsupdate retrouve sa route
?
OUI (j'ai testé!)
Windowsupdate installe les "$NTuninstall..." dans %windir% , puis les
"KB...." dans %windir%$hf_mig$ , donc que ce soit une jonction ou un vrai
répertoire, il n'en a rien à faire, c'est transparent pour lui, ce qui
compte c'est que le chemin "%windir%$hf_mig$" existe !
--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org
J'utilise déjà ton delunistall qui fait merveille. Avec presque une centaine de patches je gagne quelques 450MB en FAT32.
Je reste en fat32 pour pouvoir utiliser un vieux ghost sur disquette. En plus j'ai peur des métadonnées dont j'ignore tout.
Dans ton cas de figure en NTFS, est-ce que windowsupdate retrouve sa route ?
OUI (j'ai testé!) Windowsupdate installe les "$NTuninstall..." dans %windir% , puis les "KB...." dans %windir%$hf_mig$ , donc que ce soit une jonction ou un vrai répertoire, il n'en a rien à faire, c'est transparent pour lui, ce qui compte c'est que le chemin "%windir%$hf_mig$" existe !
-- May the Force be with You! La Connaissance s'accroît quand on la partage ---------------------------------------------------------- Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org
Jean-Claude BELLAMY
"Gilbert_13MRS" a écrit dans le message de news:
Bonjour,
et deluninstall ? Trouve-t-il aussi son chemin ?
La manip de migration + junction de $hf_mig$ ne concerne nullement deluninstall ! Il ne peut donc en être affecté.
Et MÊME SI c'était le cas, le dossier $hf_mig$ étant toujours là, çà ne changerait rien ! A moins de faire appel à des fonctions du style "getFileInformationByHandle", une appli ignore si un répertorie est un vrai répertoire ou une jonction vers un autre répertoire.
-- May the Force be with You! La Connaissance s'accroît quand on la partage ---------------------------------------------------------- Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org
"Gilbert_13MRS" <Gilbert13MRS@discussions.microsoft.com> a écrit dans le
message de news:BEA94079-A180-4473-896F-10151A48FB3B@microsoft.com...
Bonjour,
et deluninstall ? Trouve-t-il aussi son chemin ?
La manip de migration + junction de $hf_mig$ ne concerne nullement
deluninstall !
Il ne peut donc en être affecté.
Et MÊME SI c'était le cas, le dossier $hf_mig$ étant toujours là, çà ne
changerait rien !
A moins de faire appel à des fonctions du style
"getFileInformationByHandle", une appli ignore si un répertorie est un vrai
répertoire ou une jonction vers un autre répertoire.
--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org
La manip de migration + junction de $hf_mig$ ne concerne nullement deluninstall ! Il ne peut donc en être affecté.
Et MÊME SI c'était le cas, le dossier $hf_mig$ étant toujours là, çà ne changerait rien ! A moins de faire appel à des fonctions du style "getFileInformationByHandle", une appli ignore si un répertorie est un vrai répertoire ou une jonction vers un autre répertoire.
-- May the Force be with You! La Connaissance s'accroît quand on la partage ---------------------------------------------------------- Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org
JF
Salut JC Quand on sauvegarde la partition, le dossier n'est plus sauvegardé avec Windows je suppose. Et il faut refaire le lien symbolique lorsqu'on recrée la partition. C'est bien ça ?
Le SP3 prévu pour 2008 devrait faire fondre à nouveau ce $hf_mig$. C'est ainsi que ça a été observé avec les SP1 et SP2 ?
-- Salutations, Jean-François Index du site de PN : www.d2i.ch/pn/az Outlook Express : Suivez vos fils avec [CTL+H] Montrez-nous ce que vous voyez : http://fspsa.free.fr/copiecran.htm
Salut JC
Quand on sauvegarde la partition, le dossier n'est plus sauvegardé avec
Windows je suppose. Et il faut refaire le lien symbolique lorsqu'on
recrée la partition. C'est bien ça ?
Le SP3 prévu pour 2008 devrait faire fondre à nouveau ce $hf_mig$.
C'est ainsi que ça a été observé avec les SP1 et SP2 ?
--
Salutations, Jean-François
Index du site de PN : www.d2i.ch/pn/az
Outlook Express : Suivez vos fils avec [CTL+H]
Montrez-nous ce que vous voyez : http://fspsa.free.fr/copiecran.htm
Salut JC Quand on sauvegarde la partition, le dossier n'est plus sauvegardé avec Windows je suppose. Et il faut refaire le lien symbolique lorsqu'on recrée la partition. C'est bien ça ?
Le SP3 prévu pour 2008 devrait faire fondre à nouveau ce $hf_mig$. C'est ainsi que ça a été observé avec les SP1 et SP2 ?
-- Salutations, Jean-François Index du site de PN : www.d2i.ch/pn/az Outlook Express : Suivez vos fils avec [CTL+H] Montrez-nous ce que vous voyez : http://fspsa.free.fr/copiecran.htm
