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