Upgrade/update fails with permission error

[docswab]

Up to and including AI v 8.3, we had been able to perform upgrades of our product successfully using just the stock "install per-machine" or "install for this user" settings (no special permissions on any items in the APPDIR, etc.)

After that, including AI v 8.7, upgrades fail with the following error message on Windows 7:
"Error writing to file e:\simutext\imageformats\qgif4.dll. Verify that you have access to that directory"

"simutext" is the APPDIR properly set in the project, and the imageformats folder is the first file/folder in the APPDIR. qgif4.dll is the first file in that folder. So the permission failure seems to be happening on the first file that the installer attempts to replace during the upgrade.

The upgrade process has been set to install the upgrade first, and remove the old version second. We had previously used remove first/install second, but that also generates the same error.

This particular example comes from our USB drive installation setup, but we get the same problem when the program is installed normally on the C: drive per-machine with admin access, and is being upgraded with the same level of access.

Any guidance would be most welcome, as we had a system that worked before and now doesn't, and don't know what has changed or what we should change.

Two logs are attached for your review.

[mihai.petcu]

Hello,

I am not sure why you are getting this behavior. Can you please send us the .AIPs ( target and upgraded project files ) to support at advancedinstaller dot com so we can investigate them?

All the best,
Mihai

[docswab]

Thank you Mihai. The .aip files are on their way.

[mihai.petcu]

Hi Erik,

Everything seems ok in your .AIPs and log files, but since you are using synchronized folders I can only assume certain things. The error you are getting indicates that folder may not have the appropriate write permissions.
The permissions should be inherited. This is explained in the article describing the LockPermissions Table. If the permissions are not inherited, then there might be a problem with them. In this case the solution you can try would be to create a custom action which uses XCACLS.EXE to set the permissions for the folder in question.

If this doesn't solve the issue, please contact us.

All the best,
Mihai

[erik_nMT]

We're assuming that the installer features described in the MSDN page (URL provided above) are manipulated, within an AI project, in the Resources:Files and Folders panel. Given that assumption, is there any *specific* permissions setting to apply to a file -- especially a .dll file, which may by default be protected from overwriting -- that we should try in our .aip files, so that our update will work like it did back in v8.2?

It seems unlikely that an installation as basic as ours would have to have custom actions, unless you mean before the package build even runs. But if that's truly needed, how do we go about setting it up?

[erik_nMT]

Further investigation has shown that in our situation, the upgrade can be successfully performed (using the same .aip files we sent you earlier in this thread, modified to allow install on a fixed drive) in the following situation. If we load the target install on a C: drive and then run the upgrade on the C: drive, it works fine. In other words, we do not encounter a permissions problem unless we are installing to the removable drive! This suggests that the problem was never with permissions on the individual files and folders, but rather something about installing on a removable disk/USB stick.

As we have run our tests, we can see that the installer removes the files it needs to overwrite, but then produces the error message when it tries to write the (new) file back to the subdirectory.

So now the question becomes, is there a way to get around this problem with .aip settings? What do we need to do to have a working updater/upgrade for an application that was originally on a USB drive?

[mihai.petcu]

Hello,

We tried to replicate the behavior on our test machines using your project files and everything installed without error.

Does this behavior manifest while trying to install on USB from a Windows XP machine?

This may be a OS or Windows Installer specific issue. You can try to install on other machines to validate this assumption.

All the best,
Mihai

[erik_nMT]

Not XP, Windows 7.

[mihai.petcu]

Hello,

Our tests were performed on a Windows Vista machine, but there would have been some known reason ramifications if the fail occurred on Windows XP. For example the "Per machine/Per user" installation type has a different behavior on Windows Vista or above than on Windows XP.

In this case you can try to install on other similar machines and see the outcome.

All the best,
Mihai

[docswab]

Here is what we see after a few more tests:

The upgrade on top of a previous version (different product code) SUCCEEDS when:
- Installing to the C: drive in XP, Vista, and Win 7
- Installing to the E: (removable USB drive) in XP

Upgrade FAILS when installing to the E: drive on Vista and Win 7 even though we are:
- Running as an Administrator
- Completely disabled UAC on Vista.
- Confirmed that there are no Local Group Policies configured for removable storage devices.

Watching the directories and examining the logs shows that the installer IS REMOVING the previous files in preparation for adding the new versions. But then when the installer tries to add back the main .exe file, the log shows:

Code: Select all

MSI (s) (F4:38) [13:35:00:053]: Note: 1: 2318 2: E:\SimUText\SimUText.exe 
MSI (s) (F4:38) [13:35:00:053]: Note: 1: 1304 2: E:\SimUText\SimUText.exe 
Info 1304. Error writing to file: E:\SimUText\SimUText.exe.  Verify that you have access to that directory.

(after that, the first subfolder/file in the APPDIR also generates the same error and the installation fails)

When the installer is running on the C: drive, it does this:

Code: Select all

MSI (s) (F0:40) [14:12:34:763]: Note: 1: 2318 2: C:\SimUText\SimUText.exe 
MSI (s) (F0:40) [14:12:34:763]: Note: 1: 2360 

(and continues with writing out all of the files, and finishes successfully).

The logs for E and C drive upgrades are essentially identical before the attempt to replace the main EXE file, so it does not appear to be anything in the registry, etc.

Does this suggest anything to you? Thank you in advance.

[mihai.petcu]

Hello,

Upgrade FAILS when installing to the E: drive on Vista and Win 7

Does the upgrade constantly fail on several Windows Vista and Windows 7 clean machines? I'm trying to find out if this behavior is isolated or generic.

All the best,
Mihai