Installer continues even if files were locked...

[Doug I]

I ran across my first big problem with SB5 yesterday. I ran an installation that appeared like it was installing without a problem. However, since the application is running on the LAN, there was no way for me to know that someone was still in the program when I thought everybody had exited properly.

The installer continued working even though the dll's and exe's were not copying due to the files being locked by another station. I would have expected an error message or something to let me know that it had failed.
In Installshield, you would get an error which immediately told me that someone had not exited (although the error was cryptic in nature).

I would prefer SB giving me either:
1. An immediate error message and then dumping out.
2. An immediate error message with the option to continue anyway.
3. An error message at the end stating that it was unsuccessful at installing xx files and that the installation may not have worked correctly. A detail button on this error message would then optionally display those files that failed to copy for one reason or another.


Now, I would prefer option 3 myself, but will settle for any of them at this point. The way it is set up now, I have no idea the installation failed me, and then I am going into the program thinking that everything is fine. This is definitely not good. :(

Doug

[linder]

Dough,

Can you reproduce this? On our test machines (and if files are in-use) the installer asks for a reboot to complete the installation. And if I use the "Delayed File Install" feature, it rolls-back to the previous state.

Last weekend we have tested this feature on a large server farm on more than 200 different machines without any problem (using build #1158).

[linder]

Just tested this on two development machines. 25 files were in use and the installer asked to reboot. After that the locked files where replaced with the new version.

Then I tried the "Delayed File Install" functions - the installer stopped immediately and rolled back.

[Doug I]

hI Friedrich,

First off, I am on build 1158 (I believe your latest).

I did notice that the installer asked for a reboot afterwards. I have to admit, this type of install is new to me and I am a bit confused as to how the OS handles this case.

Are you are suggesting that after rebooting the pc, the files will ultimately copy over the locked files?

What if the other pc on the LAN is still in the program while I reboot the current workstation that was used for the installation?

How would other stations behave if some pc's are running a newer version of dll's/exe than other stations that are currently still in the program?

The "Delayed File Install" sounds like what I am after, but your doc's aren't complete here. How do I tell the installer to put everything back if it is unsuccessful at copying any of the files during the install process?


Lost and Confused. :confused:
Doug I.

P.S. Not sure why you keep referencing me as "Dough", when my Last Name begins with an I. DougI or Doug should suffice. My fault for not correcting you much earlier. :)

[linder]

Hi Doug,

Sorry for misspelling your name :)

To replace files that are currently in use by the operating system or another program, you have to reboot the machine. If you don't do this then the installation is not complete.

"Start Delayed File Install" and "Stop Delayed File Install" make sure that no file is replaced or installed on the user system before the script engine made sure that all files can be written.

You start your installation and the installation process begins. The delayed file install makes sure that all files are written into a temporary folder and files to be replaced are checked. No other installation system supports such a feature! If all files can be written, the installer replaces the files. If there where locked files detected, the rollback process removes the files from the temporary folder.

HTH,

[Doug I]

With respect to rebooting to install locked files, I still don't get it. Does every workstation on the entire network have to reboot? The Server?
I don't see how a reboot would install previously locked dll's/exe's that were not copied due to another station using these files. Now, if the server must be reboot, then that would make sense because everyone would have to logout anyway. I'm very confused as to how this reboot feature overcomes network locked files. Rebooting from the station you did the install will not unlock the network files, as far as I know.


Now with respect to the Delayed File Install feature... Do I simply put the command at the very beginning of my installation script and that's it? It looks straightforward, but I just want to make sure I'm correct on this. By the Way, this is a great feature and is the best of all worlds.

Does the user get some sort of message when the Delayed File Install feature was unsuccessful?

Later,
Doug

[linder]

Doug,

You have to reboot the machine that has the locked file(s).

BTW, there is a new function in the upcoming build to check if a Folder Tree has locked files.

Please put the Delayed File Install functions around your files (before the first file and after the last file definition).

Does this help?

[Doug I]

You have to reboot the machine that has the locked file(s).


Reboot which machine? The workstation pc you just did the install on, or the workstation that is actually locking the files? I don't see how rebooting the pc where the install was done will correct the locked file status occurring from some other station on the network.

Maybe you are assuming that the locked files exist on the physical drive of the pc you are rebooting? If so, this is not the networked environment I am referring to. I am referring to a server environment where the entire program is installed and resides on a network server that is rarely rebooted. The workstations merely have desktop shortcuts to access the program.


As far the Delayed Install method, I was able to get it to work. I'll be doing some tests later to ensure that it works as advertised. :)

[linder]

Yes, I understand. But if you install files and one or more files are locked, you have to reboot the machine that has the locked file. No other way to replace it. That's how the MoveFileEx Windows API works.

HTH,

[Doug I]

Ok. Now at least I understand what you are doing. I don't think its practical in my opinion. I think it's easier to just let the user know that the installation was unsuccessful and not try to assume that the user is smart enough to find the offending station on a LAN in order for the installation to complete correctly.


This being said... I did a test on the Delayed File Install method and was not happy at all with the results. It basically behaved in the same poor manner that I was originally complaining about. The installer never complained that it was unsuccessful at copying the files to the directory with locked files. At the end of the installation, it did ask to reboot the pc, but this is not the desired effect I thought I would have witnessed. I assumed the Delayed File Install method would rollback the entire process and simply provide a message at the end of the installation stating that the installation was unsuccessful.
The reboot message is just not very intuitive. An end user would have no idea what is going on and would not understand why the installation did not take... even after rebooting their pc.

Something has to be done in this area to make it clearer for a layman doing an install over a network. I hated Installshield's cryptic error message that occurred when it failed to copy installation files over a locked network file, but at least the user knew immediately that the installation had failed.

Please let me know if there is something I can do in the script to achieve the results I am expecting.

[linder]

The "Delayed File Install" method asked to reboot? IMO, this is not possible because it does not overwrite "locked" files. It checks whether all files (between the Delayed File Install function) can be written. If this is not the case, the installer rolls back (to make sure previous system modifications are removed). It then terminates the installation, but it does not replace any file so a "Reboot" message does not make any sense to me.

What you can do is to check if all files can be written. If this is not the case, display your own error message and exit the installation.

But what happens if you have checked all files before installation, and then one second after you checked the files a workstation locks files. Same problem... The MoveFileEx Windows API needs a reboot. Perhaps this scenario causes the reboot message even if you are using Delayed File Install.

BTW, this is the original restart message:

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.

You can change this to whatever you want.

HTH,

[linder]

"Delayed File Install" issue fixed in our latest internal source codes.

Thanks,