This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Re: Read-write files under Vista?
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 17, 2007
12:38 AM
Read-write files under Vista?
My default installation has subdirectories under the main program directory under "Program Files" that contain read/write files needed by the app. When installed on Vista, these files cannot be written to. Using Installshield 2008, what are my options to resolve this problem so my app works under Vista? I would prefer not to change the directory structure, since it would involve a significant documentation and code change. I'd like to make this work with a simpe IS 2008 setting if possible... is it?
(9) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 17, 2007
08:27 AM
If your app is running as administrator, then it can write to these files within the Program Files directory, I believe. Simple solution but not the best method for long term Vista compatibility.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 17, 2007
08:33 AM
As far as I can see from your post, you really only have two choices.
1) Require the app to run as an administrative user, which will give them the ability to write to the files under Program Files. This is not very user-friendly.
2) Rewrite the app structure to put the writable files in a location such as
%userprofile%\Application Data. This is better for the user, but will require much more work.
1) Require the app to run as an administrative user, which will give them the ability to write to the files under Program Files. This is not very user-friendly.
2) Rewrite the app structure to put the writable files in a location such as
%userprofile%\Application Data. This is better for the user, but will require much more work.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 17, 2007
10:03 AM
A third option would be to use LockPermissions or a custom action (perhaps using cacls.exe) to apply more permissive access controls to a location under ProgramFilesFolder (ideally a subdirectory of your program's folder, or some specific files, so the potential for malicious damage is limited). This does not follow best practices, so I wouldn't recommend it, and definitely search for the problems with LockPermissions before going that route.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 26, 2007
04:42 PM
Use the icacls.exe utility on Vista and the cacls utilty on XP to set permissions on your \Program files\My App folder.
The LockPermissions table has no means of allowing any of your files or folders to inherit any permissions from the parent folder.
Use one of those command line utilities from a custom action and add an entry for Everyone (or whatever group you prefer) to your application's files or folders.
icacls is a cleaner solution but is not supported on XP or prior.
icacls sets up inherited permissions
cacls traverses the folder structure and sets permissions on each item individually.
The LockPermissions table has no means of allowing any of your files or folders to inherit any permissions from the parent folder.
Use one of those command line utilities from a custom action and add an entry for Everyone (or whatever group you prefer) to your application's files or folders.
icacls is a cleaner solution but is not supported on XP or prior.
icacls sets up inherited permissions
cacls traverses the folder structure and sets permissions on each item individually.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Mar 13, 2008
07:15 AM
I haven't found a combination that allows the icacls.exe command to run from a custom action. Any ideas?
Here is my command info:
FILE LOCATION: C:\Windows\System32
COMMAND LINE: icacls.exe [INSTALLDIR]*.* /grant Everyone:F /C /T
Here is my command info:
FILE LOCATION: C:\Windows\System32
COMMAND LINE: icacls.exe [INSTALLDIR]*.* /grant Everyone:F /C /T
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Mar 13, 2008
09:30 AM
You will need to double-quote the filename or foldername you are passing to icacls.
E.g. "[INSTALLDIR]*.*"
It has been a while; I don't remember if you need a backslash in there, so try it without first, then with.
Keep in mind that when files are created, they inherit permissions from the parent folder, so it may be more prudent to set permissions on the folder instead of all files in the folder.
E.g. "[INSTALLDIR]*.*"
It has been a while; I don't remember if you need a backslash in there, so try it without first, then with.
Keep in mind that when files are created, they inherit permissions from the parent folder, so it may be more prudent to set permissions on the folder instead of all files in the folder.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 23, 2009
09:39 AM
MichaelU wrote:
A third option would be to use LockPermissions or a custom action (perhaps using cacls.exe) to apply more permissive access controls to a location under ProgramFilesFolder (ideally a subdirectory of your program's folder, or some specific files, so the potential for malicious damage is limited). This does not follow best practices, so I wouldn't recommend it, and definitely search for the problems with LockPermissions before going that route.
We are in the same general situation, and in the short term considering the "LockPermissions" route for our point release, and reconfiguring our products to use the AppData folders for these files in our next major release when we will have sufficient time to devote to testing.
We generally want our users to be able to modify the files we're storing in subdirectories of "..\Program Files\OurAppName" and to be able to do so while running our app, or through Windows Explorer.
With this in mind, my sense is that our best short-term solution is to set looser access permissions for these directories. I assume that the "run as administrator" option won't fly when a user needs to change something from Windows Explorer.
Are there any other options available to us that have not been mentioned in this thread that may be better, and that would work with our time constraints (~30 days from today)?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 28, 2009
10:56 AM
:confused: I've just learned that the "Users" group permissions setting is not valid for many non-US English locales. That is, when I try to install on a Finnish language version of Windows XP (SP3, all updates, etc.) I get Windows Installer Error 1609.
Time to read more about LockPermissions and/or cacls - I'm hoping I can pass an environment variable to this table...
Suggestions very much appreciated - Thanks!
Time to read more about LockPermissions and/or cacls - I'm hoping I can pass an environment variable to this table...
Suggestions very much appreciated - Thanks!
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 28, 2009
12:26 PM
Using "Everyone" in place of "Users" in LockPermissions fixed the error, and lets our app work on other OS locales, but I'm not thrilled with the solution - feels like going from a bad practice to an awful one.