Delete files inside $hf_mig$ ?

Sponsored Links

I've had SP2 and updates installed for a while and all is working well. I'd
like to delete the folders inside the $hf_mig$ file. I've heard not to
delete the $hf_mig$ folder itself. May I delete those folders without
affecting my XP Home system?

Do not delete that folder. Leave it alone. It is a necessary folder for future updates
etc.
Description of the contents of Windows XP Service Pack 2 and Windows Server 2003 software
update packages
http://support.microsoft.com/default...b;en-us;824994
%windir%\$hf_mig$ folder

You can delete these update uninstall folders/files -
Folders that have uninstall as part of the name (for example $NtUninstallKB282010$ which
reside in C:\windows (hidden folders) are Window Hot Fix Update folders/files) can be
safely deleted (providing you never wish to uninstall the updates). I would recommend
leaving these folders for a period of at least a month to make sure the update is working
correctly.

These updates can be deleted individually or in multiples. To find out more about the
update/s go to:
http://support.microsoft.com/?kbid=XXXXXX
NB: XXXXXX = the actual number not including the "Q" or "KB"

Once you have deleted the uninstall folders/files, then go to Control Panel, Add/Remove
Programs. Select the matching Windows Hotfix Title relating the update folder/file you
have just deleted and select remove. You will get a Windows error. This is because you
have deleted the uninstall folder/files. Just choose OK and the entry will be deleted from
the Add/Remove Programs Listing.

I'll keep the FOLDER. What about the KB##### folders inside of it? Can I
delete those?

Instead of deleting these files, may I move the $hf_mig$ folder to a drive
with more space? I need to clear up quite a bit of space on my C: drive and
this folder, while important, seems to be a big waste of space.

Admittedly storage is cheap, but atleast in my situation I'm in a VM
environment and I cannot expand the C: drive.

Moving it temporarily I think will work for me.

*** ONLY *** if you move the folder back prior to installing updates.
The updates check the Version of the file being installed against the
Version of the file that was updated previously.

Suggest you delete the $NtUninstallKBxxxxxx$ folders as Taurarian
suggested and clean out the %temp% folders of each User Account.
Delete Temporary Internet Files via Internet Options in the Control
Panel on the General page, too. And, limit the amount of space the TIF
folder holds and have IE delete the TIF after closing the browser.

How to Delete the Contents of the Temporary Internet Files Folder
http://support.microsoft.com/kb/260897

How to Adjust Cache Size for Temporary Internet Files
http://support.microsoft.com/kb/155353

Or, buy a bigger Hard Drive as they are relatively inexpensive
nowadays

If your Windows version is installed on a NTFS partition, maybe you can
create a NTFS junction for the <$hf_mig$> folder to another NTFS drive,
so that you won't have to move it every time. I don't know when the
junction is activated by the system, and especially, if some updates
need to alter the system during boot time, the junction may not work yet.

Can someone confirm it won't bring any problem using a junction for that
folder please ?

Try to compress that particular folder. It saved me about 150MB!

NEVER delete nor compress $hf_mig$. The subfolders contained therein
determine the branch of an update:

Description of the contents of Windows XP Service Pack 2 and Windows
Server 2003 software update packages
http://support.microsoft.com/kb/824994

If you need to reclaim disk space, see this

I want to Save Space and delete unnecessary files after installing a
Windows Update patch or Service Pack.
http://www3.telus.net/dandemar/spack.htm

Leave $hf_mgt$ alone.

Why? - provide specific, concrete reasons other than those already given.
I have done exactly what I said since XP was released and never had a single
problem.

I came across this thread rather belatedly!
I am surprised that no-one has pointed out that many of the files in
$hf_mig$ _can_ be deleted perfectly safely, since they are only duplicates
(apart from different versions) which serve no useful purpose:

$hf_mig$\KBnnnnnn\
spuninst.exe
spmsg.dll
$hf_mig$\KBnnnnnn\update\
update.exe
spcustom.dll
updspapi.dll
eula.txt

- as well as all 'KB*.log' files in the Windows directory and 'KB*.cat' in
system32\CatRoot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\

Together with %systemroot%\$NTUninstall KBnnnnnn$\ and _all_ the files in
%systemroot%\SoftwareDistribution\Download, that clears a lot of wasted
space: I have often gained over 600MB on an uncleaned system with ~180
updates.

"Buy a bigger disk" to store more wasted space is a pretty silly suggestion!
- one should learn to manage better the space available.

Clean up and uninstall everthing you never use* - that lets me fit a
complete ASR backup of my XP SP2 Pro with a very wide range of programs on 1
DVD.

* for example all of the following can be removed (see my site for details):
Movie Maker
Netmeeting
Outlook Express
Microsoft Frontpage
Windows Media Player
Windows Messenger
MSN
Voice synthesis
Microsoft Agent
Wordpad
Communications (unused components)
Games
Accessibility

You're post is EXTREMELY DANGEROUS, bitwyse as it contains INCREDIBLY
WRONG MISINFORMATION !

The problem with it is, if a naive User reads it and follows your ABSURD
MISINFORMATION, their XP system will ***NEVER*** be able to install
updates again !!!

In XP, the files in $hf_mig$ are used to determine which *Branch* of an
update should be installed.

" When a security update, critical update, update, update rollup,
driver, or feature pack installs GDR version files, the hotfix files are
also copied to the %windir%\$hf_mig$ folder. This supports migration to
the appropriate files if you later install a hotfix or service pack that
includes earlier versions of these files. For example, consider the
following scenario:

1. You apply a security update that installs a GDR version of
File.dll with a version number of 5.2.3790.1000 and copies a hotfix
version of File.dll with a version number of 5.2.3790.1000 to the
%windir%\$hf_mig$ folder.
2. You apply a hotfix that includes a hotfix version of File.dll
with a version number of 5.2.3790.0000.

In this scenario the hotfix installation in step 2 installs the hotfix
version of File.dll (version number 5.2.3790.1000) from the
%windir%\$hf_mig$ folder instead of the hotfix version of File.dll
(version number 5.2.3790.0000) from the hotfix package. "

Source: http://support.microsoft.com/kb/824994

The Catroot subfolder contains the Security Catalog database which
determines if system binaries are digitally signed. The *lack* of signed
system files is what is causing some XP systems to fail to install
KB971486, the October Kernel update. The KBxxxxxx.cat file is the
digital cert of Security Updates, which is then referenced by the
CatRoot2 subfolder:

Vulnerabilities in Windows Kernel Could Allow Elevation of Privilege
(971486): MS09-058
http://www.microsoft.com/technet/sec.../MS09-058.mspx

NO XP system should *EVER* have *ANY* contents of the CatRoot subfolder
deleted. *** EVER ***
CatRoot2 can become corrupted and that is the ONLY catroot subfolder
that should *EVER* be deleted.

> (see my site for details)

Why wouldn't anyone believe that when you obviously are *completely
ignorant* on how XP updates ?

Perhaps if you used an NNTP news reading client instead of a web browser
(X-Newsreader: Microsoft CDO for Windows 2000) then you'd be able a
COMPLETE REFUTATION of your lack of knowledge in regards to updating
Windows XP:

You're post is EXTREMELY DANGEROUS, bitwyse, as it contains INCREDIBLY
WRONG MISINFORMATION !

The problem with it is, if a naive User reads it and follows your ABSURD
MISINFORMATION, their XP system will ***NEVER*** be able to install
updates again !!!

In XP, the files in $hf_mig$ are used to determine which *Branch* of an
update should be installed.

" When a security update, critical update, update, update rollup,
driver, or feature pack installs GDR version files, the hotfix files are
also copied to the %windir%\$hf_mig$ folder. This supports migration to
the appropriate files if you later install a hotfix or service pack that
includes earlier versions of these files. For example, consider the
following scenario:

1. You apply a security update that installs a GDR version of
File.dll with a version number of 5.2.3790.1000 and copies a hotfix
version of File.dll with a version number of 5.2.3790.1000 to the
%windir%\$hf_mig$ folder.
2. You apply a hotfix that includes a hotfix version of File.dll
with a version number of 5.2.3790.0000.

In this scenario the hotfix installation in step 2 installs the hotfix
version of File.dll (version number 5.2.3790.1000) from the
%windir%\$hf_mig$ folder instead of the hotfix version of File.dll
(version number 5.2.3790.0000) from the hotfix package. "

Source: http://support.microsoft.com/kb/824994

The Catroot subfolder contains the Security Catalog database which
determines if system binaries are digitally signed. The *lack* of signed
system files is what is causing some XP systems to fail to install
KB971486, the October Kernel update. The KBxxxxxx.cat file is the
digital cert of Security Updates, which is then referenced by the
CatRoot2 subfolder:

Vulnerabilities in Windows Kernel Could Allow Elevation of Privilege
(971486): MS09-058
http://www.microsoft.com/technet/sec.../MS09-058.mspx

NO XP system should *EVER* have *ANY* contents of the CatRoot subfolder
deleted. *** EVER ***
CatRoot2 can become corrupted and that is the ONLY catroot subfolder
that should *EVER* be deleted.

Why wouldn't anyone believe that when you obviously are *completely
ignorant* on how XP updates ?

Yeah, I've read all that before.

So consider the following scenario:
KB123456 has been installed, then
%systemroot%\$NTUninstallKB123456$\ has been deleted, together with the
information in the registry at
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall
an
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\AppManagement\ARPCache

So why would
%systemroot%\system32\CatRoot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\KB123456.cat
ever be needed again? It no longer signs anything at all!

Actually, all the confused ideas in this thread tempt me to go even further.

Supposing (in general terms) that the files (version 1000) installed by
KB123456 have since been replaced by later versions (1001) of the same files
by KB234567. According to the arguments already repeated, if ever version
1000 is proposed again, it will be instead the later version 1001 from
$hf_mig$\KB234567 which will actually be used. So in fact $hf_mig$\KB123456
is no longer needed.
And so on... If KB345678 replaces KB234567 in turn with version 1002, there
is even less need for the older version.

So by carefully analysing successive versions of the same files replaced by
later updates (taking account of the branch), we could also delete the older
versions in $hf_mig$ which have become totally redundant.
For example, in my scenario, the obsolete (because already replaced twice)
versions 0998 and 0999 from previous KBnnnnnn would never be needed again.

Presumably Windows Update isn't that stupid? (mind you anything is
possible...). If indeed it is - it's past time to update the programming team!

Correction - it still signs what remains in $hf_mig$.
I changed the order of what I wrote and anticipated the following train of
thought which would eliminate that as well.

This is probably true, although I'm not certain that there isn't a subtle catch
somewhere. In any case the very small amount of space you could save by this
approach is unlikely to be worth the effort and risk involved.

Another idea to try - NOT YET TESTED.

At the key
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\WindowsXP\SP3\KBxxxxxx\Filelist\y
there is often a value like
"Location"="c:\\windows\\$hf_mig$\\KBxxxxxx\\update"

Now what if we move the folder and change the location - for example to
"d:\\$hf_mig$\\KBxxxxxx\\update"

To check: is this location also recorded elsewhere?

Agreed - my time is better spent on something worthwhile.

I wouldn't probably even consider the risks - as the 'benefits' wouldn't
even tempt me into it originally. hah

A few MBs in a TB world just isn't high on my list. ... And if I made a bad
decision and/or just kept the machine so long that it is legitimately
running out of space - I think I can afford the $20-$100 for
double/triple/10+ times the space it originally had and/or move the stuff
that shouldn't be on that drive/partition elsewhere with the time I would
waste trying to reverse-engineer the mysteries of an 8-year old OSes
'updating system quirks'. ;-)

(BTW - this stupid forum management program doesn't allow you to edit your
own contributions; 9 times out of 10 you can't log in directly but have to do
it elsewhere; and the e-mail reply notification loops infinitely and simply
doesn't work - but then maybe it uses some trick that my
configuration/firewall won't allow - quite rightly.)

....and additionally there is still a copy of the 'KB*.cat' in the same
sub-folder!
How many duplicate files do we need? - if I shouldn't delete the CatRoot
copy, then I can delete the $hf_mig$ copy...
(but I'm now working on how to get rid of everything that is obsolete - so
any precise, detailed information will be much appreciated)

Thanks for the information. It's certainly much easier in a newsgroup.
I just found the web interface while searching Internet for more
precise, detailed information than KB824994; and hoped to get some
insider tips.
Why bother? - see my reply to Harry ;-)

(I found a solution to the login problem: when invited, delete all the
cookies planted by microsoft.com and live.com: go to MSN and log in,
then return directly to the original page. It works most times.)