Can I erase Config.msi?

[Madman]

I've been doing some disk cleaning today and what shocked me is that scanner (http://www.steffengerlach.de/freeware/) which is one of the handiest tools ever made, displayed config.msi on my C: drive as one of the most bloated folders, weighting at 900MB.

I've done extensive goggling but I cant find any information that said it's safe or unsafe to delete it.

From my experiences so far I have a strong feeling that this folder is keeping unneeded bloat of Microsoft installer, which is a parody by default.

Given that I had Visual studio SP1 installation fail twice because 5Gb space was not enough for the update, I imagine the directory might be full with 'stuff', but I can't find any proof of that.

Does anyone know anything about this beast?

[soccergenius]

Where is config.msi on your computer, so I can compare? I tried looking on mine and only found c:/windows/config <--which is completely empty. I think though, the most common response you're going to get is, "Get a bigger HD." There's no excuse not to!

[computron9000]

config.msi shouldn't be a huge folder.

[Madman]

c:\config.msi

It's hidden by default, and files inside are hidden too. You wont see it from Explorer. I think only FAR shows the directory in it's full grace.

Well the Scanner i mentioned should display it too if it's big.

EDIT: Just checked with far, 900MB in 1900 files, only 2 are non-hidden.

[computron9000]

http://forums.pcworld.co.nz/archive/ind ... 23650.html

[Madman]

Well, Office is only 90MB when installed and I did that only once...

[computron9000]

the point of my post was that it/they is/are useless. rename it. msi = Microsoft Installer files. if nothing bad happens after you rename (which it won't), delete.

[liar]

http://filext.com/detaillist.php?extdetail=RBS

"Windows Installer accomplishes rollback by creating a rollback script. A rollback script is a file that contains a linear sequence of operations to perform, such as file and registry updates, configuration information updates, user interface notifications, and state information for other operations. Each operation recorded in the rollback script is a direct response to an operation in the installation script. Rollback scripts are stored in binary format. This improves efficiency, avoids the need for parsing the file, and discourages manual editing of the file. Rollback script files (.RBS and .RBF) are backups of existing files. Files with an .RBS file extension are rollback script files, and files with an .RBF file extension are backups of existing files. Both are stored in hidden folders called Config.msi. The Config.msi folders are created when the Msiexec.exe file starts copying from the installation point. The rollback script file (.RBS) is always stored in the Config.msi folder on the disk where the operating system is installed. The .RBF files are stored in the Config.msi folder on the disk where the program that is being backed up currently resides. This is done so that there is no crossing of disks when the program files are being backed up. All rollback files and the Config.msi folders are deleted when the installation completes successfully."

[Flying Fox]

AFAIK all the rollback scripts and stuff should be cleaned up after installation is done. Windows Installer will store a smaller copy of the original MSI at %Windows%\Installer, so it should be ok to kill Config.msi. At least I have done it before with no ill effects.

[Madman]

Smoked them out and everything is silky smooth.

One more evidence that Windows installer sucks

[Flying Fox]

One more evidence that Windows installer sucks

Actually, Windows Installer is one of the best things that come along with the OS. Authored correctly, Windows installer packages can really make for a resilient and clean installation. Problem is, like most Microsoft technologies, people who shouldn't be in the business are doing the stuff and tarnished the good stuff. Dummy GUI tools certainly did not help the situation, but the more I dive into the MSI stuff (quickly falling in love with WiX), the more respect I have for the MSI team. Convoluted and complex may be, but I can certainly understand most of the reasons behind the design decisions.

As long as you don't try to nickel and dime disk space, which with today's cheap large HDDs makes this almost a non-issue.

[Madman]

I don't know, registering all that crap, having huge database generated at install time, copying stuff 10 times over the same drive, doesn't sound reasonable to me.

Maybe it's because I started from programming OpenGL stuff where you try to keep resources next to your exe in some binary form, but xcopy simply smokes everything out.

EDIT:

Problem is, like most Microsoft technologies, people who shouldn't be in the business are doing the stuff and tarnished the good stuff.

Ironic part is that it was the Microsoft Visual Studio SP1 that wrecked my system. And I also have some good memories about 2000 Office installation. Luckily I don't use MS Office anymore.

By the way, there is a tool called MSI cleaner or something right in Microsoft office support section

[Flying Fox]

The database is needed to make sure all the dependencies are recorded and restored when needed (in a repair install or on-demand install).

I don't see files copied over 10 times. What are you talking about? Proper component definition should make that irrelevant, or they may be doing side-by-side assemblies instead of DLL sharing hell?

Disk space, to me now, is nothing. Memory or CPU cycles I will agree. If using more disk space gives me a more resilient installation, that's good in my book.

And I haven't even got to rollbacks yet, they are very cool with Windows Installer.

[Madman]

The things are copied over at least 2 times in average. Browser to desktop, desktop to temp, temp to windows\install and if I'm not mistaken sometimes things are carried over to program files\installer or something too. Plus I would count rbf's as sorta copies too.

I wouldn't say memory is more expensive than HDD, because yea, it's smaller, but it's accelerating stuff all the time. Prefetch, superprefetch, files cache, in RAM processing.

HDD on the other hand gets bloated with unneeded files and in the end you cant even find what you can erase and what you cant.
It's always such a pain to remember to copy things like usertype.dat and such from program directories.

And I have also seen applications that are running 50% average kernel time only because MSI is checking for updated/missing/nonessential files.

So I guess I'm really negative here, but I've seen more harm from MSI than from UT2k4 xcopy like setups.