cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
jscozz
Level 4

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?
Labels (1)
0 Kudos
(9) Replies
sks2004
Level 4

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.
0 Kudos
MGarrett
Level 6

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.
0 Kudos
MichaelU
Level 12 Flexeran
Level 12 Flexeran

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.
0 Kudos
nklhead
Level 2

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.
0 Kudos
cfairweather
Level 4

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
0 Kudos
nklhead
Level 2

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.
0 Kudos
regexmaster
Level 5

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)?
0 Kudos
regexmaster
Level 5

: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!
0 Kudos
regexmaster
Level 5

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.
0 Kudos