Checking for files in use

[oeb]

It is very time-consuming to add check for files in use manually. Would it be possible to get this as built-in functionality?

At least I would like a function to check if any of the files that setup is ready to install are in use. The way it is now I have to check for every specific file that will be updated.

Folder check is not an option, since there might be files that are not updated in this installation, and having to unnecessary close an application just annoys the user. In our case we also have a critical service running that we will not close unless absolutely needed.

[linder]

No, this is (from the technical point-of-view) absolutely impossible! And you already provided an answer why this is impossible ;) During the runtime execution of the script, there might be files that are skipped. So you can't check (automatically) for relevant in-use files before the script is executed.

Hope this helps.

Friedrich

[linder]

BTW, you can try to put the "Delayed File Install" action around your files to be installed (if this is possible in your case). This will only "install" the files if all files can be written (if they are not in-use).

Friedrich

[oeb]

After I updated to SetupBuilder 8.1 I noticed strange behavior by our setup files on a couple of machines.

First, FUNCTION:check In-use returns 0 (not in use)
|11/13/2013|17:24:28.343|@CHECK ("%INUSE%" : "c:\mydir\mydll.dll" : 0)

But the file is not replaced. Instead, a Windows reboot request is triggered:
|11/13/2013|17:24:31.494|ProcessSpecialActions: 6 : C:\Users\oeb\AppData\Local\Temp\~SBE3B2.tmp : c:\mydir\mydll.dll

As I understood it this should not be possible when "Delayed File Install" is used - instead the setup operation should fail?

On most machines this works fine. Compiling the same script with SetupBuilder 7.7 works fine even on the two machines with the described behavior.

[linder]

Hello,

Do you have the "Delayed File Install" function around the file(s) to be installed? SetupBuilder 7.7 is more than one year old and as far as I can see, there was no modification in the replace in-use file functionality from SB7 to SB8. The execution behavior between a SB7 and SB8 app might be different based on the Windows operating system (because SB7 might run in compatibility mode on Win8/Server 2012 and Win81/Server 2012 R2).

If you are interested, you can send your project file to our Support and we'll review the project source code. Please also mention the OS where you see the problem and the name of the DLL(s). And the complete event.log would be great. But the event log tells us that "c:\mydir\mydll.dll" could not be replaced because it was "locked". So a correctly used Delayed File Install "should" offer a rollback and not a reboot. But it depends on the project code -- we can check this when we have received your project file. mydll.dll was definitely "locked" (e.g. by a real-time anti-virus monitoring process).

Friedrich

[linder]

BTW, the fact that "FUNCTION:check In-use" returns 0 (not in-use) and later in the script the ProcessSpecialActions reports 6 (in-use) tells us that something kicked in during the installation process that locked the mydll.dll file.

Friedrich

[linder]

FYI: we checked the SB source code and the last modification in the "in-use file" handling is dated September 20, 2010 (more than three years ago).

Friedrich

[linder]

We have tested a 8.1 setup on different machines (we simulated a "locked file" scenario) and got the following:

|11/15/2013|12:46:37.265|MainProgressDlgProcInitialized
|11/15/2013|12:46:37.405|@CHECK ("%INUSE%" : "c:\mytest\sbuilder.chm" : 0)
|11/15/2013|12:46:37.405|Set Variable %INUSE% to 0
|11/15/2013|12:46:37.405|@DISPLAYMESSAGE InUse Status: 0 :
|11/15/2013|12:46:40.977|Set Variable %_SB_RETURN% to 1
|11/15/2013|12:46:40.977|@DISPLAYMESSAGE Lock File Now... :
|11/15/2013|12:46:46.001|Set Variable %_SB_RETURN% to 1
|11/15/2013|12:47:45.499|Err02: -1001 - File: c:\mytest\sbuilder.chm
|11/15/2013|12:47:45.499|@RETURNCODE (99 : 9 : )
|11/15/2013|12:47:45.499|RunScriptEnd

The "Delayed File Install" detected the locked file and did not offer a reboot (but a rollback).

Friedrich

[oeb]

Thanks for the reply. I will send the script by e-mail.

The only other change apart from updating from SetupBuilder from v8.0 to 8.1 was adding a #ifcompvar statement around the "Install File" function for the DLL in question.

[linder]

We have compared the source code tree from SB7 and SB8 and there was no modification in the install file logic. So the only explanation I have is that "something" kicks in on these specific machine(s) and changes the execution behavior of the SB8 compiled app (locks the file after the internal check-in-use file check and then some fallback code comes into place). We have to add some more log event entries to see what is going on these machines.

Friedrich

[linder]

Quick update: we can simulate your scenario (the same might happen with a SB6 and SB7 compiled setup). In your case, the "Set Delayed File Install: Start" function copies the files to be installed into a temporary Windows folder. None of the files to be replaced at a later stage are detected as locked. After this, the "Set Delayed File Install: Stop" function replaces the original files with the queued files and suddenly, a previously unlocked file has "locked" status (the create CreateFile Windows API fails). At this stage, the installer can't rollback the actions and so the file causes a reboot request. We have to find a way to handle this very specific scenario. But it is not directly related to SB8 (all the runtime code is identical in SB6 and SB7). Perhaps the Win81-aware manifest changes some Windows internals, I don't know.

Friedrich

[oeb]

Good to hear you were able to re-create it. I have not explanation why this turned up in SB8 and not SB7. I will probably replace the "Install File" functions with my own file update handling (from a zip file included as a support file) within a DLL to have total control of the update process and be 100% sure a Windows reboot request isn't triggered.

[linder]

If you are interested, I can give you access to an internal SB81 version that includes the modified runtime (more event information and the additional in-use check to avoid the execution of the reboot fallback code). But the one million dollar question is why does "something" suddenly locks the file on this machine.

BTW, you can "disable" the pending reboot without any problem (see "Set Installer Flag..." script function). But without the reboot, the update process is not done. And the same might happen with your UNZIP idea.

Friedrich

[oeb]

I'd be happy to try the internal SB81.

I'm aware that the risk of a file lock is always there, but a Windows reboot is simply not a good solution in our case. So I just want the installation/ update to fail if this happens.