[CelestialTeardrop]

Humph. When comps decide to act up mysteriously, they serve up multiple issues. So here's another question:

I just did a system restore, and now there is an empty folder in my C:\ called 'config.msi'. It was created one minute after the restore took place. Any ideas on what might have created it?

Thanks.

[Advertisements]

turn off system restore by unchecking it.. start ..control panel..system..system restore..take check mark out click ok

try deleteing it and then reboot

if it doesnt show up should be ok

heres some info



Question
I’m uninstalling a product on Windows Server 2003. At the time of uninstall, one of the product’s DLL is in use. The log file generated during uninstall contains the following entry:


MSI (s) (A0:CC): Note: 1: 2228 2: 3: Error 4: SELECT `Message` FROM `Error` WHERE `Error` = 1903

Info 1903. Scheduling reboot operation: Deleting file C:\Config.Msi\bdc5d1.rbf. Must reboot to complete operation.




In spite of the message indicating that reboot is necessary, I’m not prompted for reboot when uninstall completes. Is there some sort of bug in my install program or is this by design?

I thought that reboot was going to automatically occur to avoid the above scenario, but apparently this isn’t so. Can someone comment on this scenario and suggest what we might do overcome this problem?

Answer
Generally this can be safely ignored.

The only authoring degree of freedom with reboots is the REBOOT Property [Windows Installer] and generally folks want less reboots not more.

.rbf files are internal copies (technically the moved original) of the files that Darwin keeps for Rollback Installation [Windows Installer] purposes. Al this says is that Darwin is going to put an entry into the windows registry to delete this file at the next reboot of the system.

The behavior by Windows Installer is by-design. This is related to the functionality that Windows NT offers for handling in-use files. Win9X systems used a replace on reboot model for updating files that were in-use. WinNT systems provided a better model that helped eliminate unnecessary reboots by providing a move-and-replace model. The Installer makes full use of the WinNT model on those platforms. When the file is in use and must be removed, the installer can simply rename it to some secret location and then schedule it for deletion at a later time. Since nobody else can find the file (they usually ask for it by its former name), the delete-on-reboot portion of the update is considered optional. Why reboot for a file that none knows about?

Currently there is no way to turn off the Installer's reboot-ignore behavior on file removal. If the behavior doesn't fit your model (and you're identified one such occurrence), then adjust your setup to make it work. You can either ensure that your file is not held in use by getting all users to unload it or alternatively authoring your setup to force a reboot for the scenario. At this point, the only identification of the state is the 1903 message sent to the log file (or to an external UI handler). There are no properties that are set to identify the scenario as ReplacedInUseFiles is only set when the Installer actually overwrites an existing in-use file.

after you reboot go back and restore your system recovery by replacing check mark back in box

[CelestialTeardrop]

Thanks rushin1nd,

I deleted the file after turning off system restore, and it's not reappearing.

I'm still not sure why it was created, but my guess is it was due to using a restore point that had an older version of QuickTime. I undid the restore but the config.msi was still on the C: drive (until I deleted it just now of course).