On my AI installer all the files in the Aplication Folder apear to be being installed with security settings granting only the local Administrator and the installing user access. In AI the permissions have not been set for either the folder or the files within it, I assume this means they should just pick up inherited permissions.
I do explicitly set permisions on three Folders under Common Application Data in this installer and searching the AI project file XML for the 'Permission' attribute I see it being applied to these three folders only.
As a test I created a second installer that just drops some additional files into the first's Application Folder, these files correctly inherit the folder security and can be read by standard users.
I'm not sure why you are encountering the behavior. Can you test the first installation project on multiple clean machines and see if the behavior still persist? If, so can you send us the .AIP (project file) and a verbose log of the installation to support at advancedinstaller dot com so we can investigate them?
Was this issue ever resolved? I have what looks like the same issue, all the installed files have their permissions explicitly set to only allow 'System', 'Administrators' and the installing user access rather than inheriting from their parent. The folders have correct permissions (i.e. c:\Program Files\Company and c:\Program Files\Company\Product are both set to inherit permissions form their parents as expected) but the individual files are incorrectly overridden. No permissions set in the AI project so I believe they should all inherit by default.
The issue isn't intermittent and seems to be 100% reproducible on any machine (XP/Win7/32/64 etc). The setup is a mixed-mode 32/64 installer using the bootstrap executable if that's relevant.
This issue means that the very typical scenario of a restricted user getting an administrator to install the product for them cannot then run the product unless the administrator manually sets the file permissions to their correct values after installation.
Unfortunately, this seems to be a Windows Installer related issue. It seems the permissions are not always inherited. As a workaround you can use a custom action to always set accordingly the permissions.
Firstly thank you for the prompt reply, much appreciated. However I'm not entirely convinced that it can simply be Windows Installer at fault here, otherwise pretty much every application on Windows would suffer this issue, also I used InstallShield Express for more than ten years before switching to Advanced Installer and (while I prefer Advanced Installer in almost every way) that also created MSI based packages but never suffered this issue.
I read the article that you linked to but that seems to be more concerned with setting custom permissions for the files (such as write access within the Program Files folder - yuck!), I don't want to do anything unusual just the normal behavior of standard users being able to run programs installed in the 'Program Files' folder no matter who installed them. That article in turn links to a page describing using 'Xcacls.exe' is this what you were referring to when you suggested to use a custom action? If so do you have an example that would set all files in the installation folder to inherit their permissions from the parent folder?
For now I have manually set the permissions for every file in the setup to 'Read & Execute' for 'Everyone' and although this appears to work I don't feel that this is a permanent solution. Firstly it relies on me setting the permissions of every new file added to the setup in the future in the same way (something that I am bound to forget to do!). Secondly the permissions shouldn't really be set to 'everyone', they should probably be set to allow just 'users' or 'domain users' or some other thing depending on how the user's machine/domain is set up (but I don't know in advance what these should be for a particular machine).
The possible workarounds really strike me as 'hacks' to create the behaviour that should simply be standard, I think there must be something else wrong here. I'm happy to send the AIP file and/or built setup .exe if if helps to diagnose the root cause of the problem? As mentioned it affects all machines that I've tried so it's not just a quirk with certain machines, it's not so much "permissions are not always inherited" it's "permissions are never inherited" for me!
That article in turn links to a page describing using 'Xcacls.exe' is this what you were referring to when you suggested to use a custom action? If so do you have an example that would set all files in the installation folder to inherit their permissions from the parent folder?
Thanks for your reply, however I continued to search for a solution rather than a hack/workaround and found the source of the bug, it seems this problem is caused by the option "Fast Installation - optimized file costing and copy, indeterminate progress". When I disable this option the installed files have the correct permissions. Hopefully this bug will be fixed in a future release but for now my setups work fine by simply turning this option off.
Indeed, when "Fast Installation - optimized file costing and copy, indeterminate progress" option is enabled the installation files don't inherit accordingly permissions. For the "Fast installation" option we use the FASTOEM Windows Installer support and, unfortunately we cannot influence this behavior.
Good to know, thanks. The software I'm installing is not very big so the time saving is minimal from using this option, I'll simply leave it turned off permanently then. Perhaps some information about this could be put on the 'Install Parameters' page next to the offending option (e.g. a help link) as I don't think many people would automatically equate "fast install" = "file permissions will be wrong unless you manually override them", could save others running into this issue in the future.