gbeardsl
12th January 2004 03:54 UTC

Locked file handling?
Kind folk,
During any installation, it's best to assume that the files you're installing may already be present on the target system, and may be locked.

To properly handle this condition, I'm using the "Rename" function with the "/REBOOTOK" option. This appears to be the only method within NSIS for handling locked file conditions. Using this method will set the reboot flag if the target file is currently locked.

The error that I'm experiencing is that if the file is present on the user system at all, then the reboot flag get's set, even if the file is not locked.

I've put many days into using the NSIS installer, and so hate to revert to InstallShield. However, if locked files can't be properly handled, I may have no choice.

This is a really common need; does anybody know of this bug, how to work around, or what is considered proper protocol in NSIS for handling locked files?

I'm using version 1.98 for a variety of reasons.

Thanks so much!
I'm desperate,
Gary

Joost Verburg
12th January 2004 07:38 UTC

There are many known bugs in the old 1.98 version you are using, it has not been updated for two years.

Upgrade to NSIS 2 and it should work fine.

gbeardsl
12th January 2004 07:50 UTC

Thanks Joost. After reading some of the other related topics, I may choose to be lazy for the moment and simply delete it first with /REBOOTOK. If it's locked, the reboot flag will be set. If it's not locked, then Rename will do the deed without the failure.

But again, Thanks!

Joost Verburg
12th January 2004 15:26 UTC

Almost all NSIS 2 features are backwards compatible, upgrading is highly recommended because it will fix several issues.

gbeardsl
12th January 2004 17:27 UTC

Point taken. However, I must ship today, and QA time is insufficient to gamble on any other failures. The delete fix works, so it's going out the door. Will use new version next build.

Thanks,
Gary

gbeardsl
26th January 2004 20:37 UTC

Joost,
Thanks for your communications and work on this codebase! Per your suggestion, I did of course update to the latest version of NSIS.

I need to ask about the current methodology for handling locked files. The support for this is still pretty convoluted if I understand it correctly. There's a high percentage of the files that I install which could potentially be locked, and realistically, I always assume any file could be locked when building an InstallShield installer. It's simply good practice and eliminates error.

For installing potentially locked files with NSIS, I cannot merely use the 'File' command. I must first unpack the files in a temp folder, then use 'Rename' to move it to the target, then check the error flag and manually set the reboot flag which I will check at the end of install to see if I should reboot.

This seems to be the only current approach; is this correct? It would certainly be nice if this functionality was all contained in the 'File' command with a 'Locked' flag. I've considered adding this myself, but am new to NSIS and don't want to start screwing with source if this effort is already underway by somebody and until I'm hooked for sure.

Any comments you have would be appreciated.

Thanks!
Gary

Joost Verburg
26th January 2004 22:07 UTC

There is no other method. InstallShield will have to do the same thing.

You can put the code in a macro it you need to use it multiple times.

The included UpgradeDLL macro handles version checks and upgrades.

gbeardsl
26th January 2004 22:50 UTC

Thanks Joost! I will check the "included UpgradeDLL macro".

FYI - InstallShield must do this also of course, but all the user does is click a checkbox for "potentially locked".

gb