Odd situation, disappearing files

[Tom H.]

Friedrich,

I've got a puzzler here, and wonder if you have any input...

The situation as described by our client is that they apply a patch of ours on the server and everything is fine. However, days/weeks later they apply an MS security patch which requires rebooting the server at which point a number of the program files installed by our patch disappear (are deleted):eek:!

Our patches do not normally require reboots as they check for in-use files and running services. The client had run into a situation before where they tried applying a patch but there was a TS user using them. They rebooted, then reapplied the patch and things are okay.

Can you think of any situation where a file might be marked for delete/replace on reboot by an SB7 patch, but just end up being deleted?

Thanks in advance,
Tom

[linder]

Hi Tom,

The default behavior is as follows. If the installer replaced a "locked" (in-use) file, a reboot is required in order to complete the installation process. Windows will then replace the file at startup. If you do not restart the machine in this scenario then you have an incomplete installation.

In theory, the following can happen in your case. You check for "in-use" files (from the installer) before the real file installation process begins. Okay, the installer did not detect any locked file because no file was in-use. But a few milliseconds after this check, a workstation suddenly "locks" a file and bang, a reboot is required to complete the installation.

By default, the installer displays a "This system must be restarted to complete the installation. Press the OK button to restart this computer. Press Cancel to return to Windows without restarting." message.

If your user does not press "OK" to reboot the machine then he ends up with an incomplete installation. If your installer does not display the "system must be restarted" message then you suppressed that message because you assumed that a reboot is never required (because you check for in-use files before the file installation process).

And this is still not the end of the story <g>. The system is in "reboot pending" state now. That means, the next reboot will replace the previously locked file. What may happen now is that "something" deletes the new file (that is ready to replace the old file at reboot) from the temporary file cache. Sometimes some smart Admins delete the files or a "clean" program does it automatically from time to time, etc. So let us assume that the files to complete the installation process are not there when the machine reboots (days, weeks or months after the installation). The Windows reboot process magically deletes the original file now! "Gone with the reboot". :)

Let us assume you have the reboot option disabled. So what you can try to do is the following. Before you start the installation, check if there is still a pending reboot (to be on the safe side).

Set Variable %REBOOTSTATUS% to FUNCTION:Get System Info(Reboot Status)

%REBOOTSTATUS% returns "1" if the system should be restarted. That means, one of the previous installations still need a reboot to complete. Report this to the user and let him act accordingly.

If there is no pending reboot, continue with the installation process and at the end, check again if a reboot is required.

If %_SB_INSTALLERFLAG% Equals "1" on Position "$SB_RESTARTFLAG$" Then
Display Message Box "Reboot required" -- ""
End

The above If statement will resolve to TRUE if your installer needs a reboot.

And if you are interested, you can do again a pending reboot check to see if a 3rd-party product switched the system into "reboot pending" state.

Set Variable %REBOOTSTATUS% to FUNCTION:Get System Info(Reboot Status)

Does this help?

Friedrich

[Tom H.]

Friedrich,

You are a fount of useful information, as usual!

One more detail I got from them, it seems the TS sessions are inactive/"disconnected" at the time. Is it possible for files to be reported as not in use in SB7 in that situation?

Thanks again,
Tom

[linder]

Hi Tom,

To be honest, I don't know. But a "check-in-use" function always checks if exclusive write access to a file is possible. If this is the case then the file is considered to be not "in-use" (locked) and it is assumed that the file can be replaced.

Friedrich

[Tom H.]

Final question on this topic. As we press them for more details, it sounds like the IT person applies our patch, gets a reboot required message, then just immediately applies the patch again without actually rebooting. Could this mess up the file replacement logic?

In any case, I will be adding the checks you suggested (and any more I can think of.) Thanks again for your assistance.

Tom

[linder]

Hi Tom,

If the IT person applies the patch again without rebooting (but the previous patch switched the system into a pending reboot state) then this should not (IMO) mess up the file replacement logic. The next patch will again detect the locked files and write another set of "files to be replaced at reboot". The next reboot will then replace the files from the first patch and after that the files from the second patch.

The "delete files" scenario can only happen when the temporary files are not available when the Windows system reboots. Windows removes the original (old) file and tries to move the (new) files from the temporary location to the final target location.

Friedrich