Randem Systems Support Board

Nice smiley!

Yes...

But, if I inadvisably ignored you, I could hard code the paths for the two installations - ?

In the installation {usercommondata}GHMDATA would be the same for either installation. What I a talking about is not having to have two different applications (one for XP and one for Vista). If you use the code I supplied you would not have to worry about which os your app was running on. The code would automatically handle it. No hard coding needed...

We have something in common and it's not an understanding of OS's, security, etc.  My Handicap Index is 8.9.  It used to be 5.0 a few years ago and I once was a 3 but that's as old as my systems knowledge.  http://www.dutchessgolf.com  I see your club took advantage of your webmaster skills.  Our folks (not including me) still use FrontPage.  I'm the Club Historian.
 
So, I can use {commonappdata}.  If I recall from previous discussion, the path for Win2K is the same as that for XP.  As was also discussed, I am going to restrict the app to Win2K, XP and Vista.  Now, IF (contrary to your recommendation) I were to go the simple route and have separate installation packages for Win2K-XP and Vista, I assume I can hard code the paths for each, including a subfolder for the app's data - {usercommondata\GHMDATA.

Yes, I understand handicapping, I am a 9 and I have a golf club Reggae Golf Crew
 
Sure in that situation you can install it in the common (All Users) Folder. {commonappdata} will go to the All Users folder, mind you that this common area is different in some Windows version and if your app doesn't handle it properly it doesn't matter what you do in installation. This is why the project I gave you is so important in that area.
 
In XP it will go to C:\Documents and Settings\All Users\...
 
In Vista it will go to C:\ProgramData
 
Your application has to be able to seamlessly use either one and not care which. So it cannot be hard coded.

No, I CERTAINLY (not probably) don't understand security, but I don't think security understands my app.  The user CANNOT affect the data in terms of physically adding to it, changing it, etc. - which is what I thought security was supposed to be all about.  Again, the user does not have direct access to the data, only the app does.
 
Perhaps there's an aspect of the app that you do not understand.  If the common data shared by all users in a given installation (again, each user does not have his/her own data) becomes erased, damaged, etc. I DO NOT want to replace the data with the default files.  The current data has historical significance.  Without going into all the specifics of golf handicappiing, a player's handicap is based on some number of the player's previous scores and is updated each time a new score for the player is entered.  Therefore, in the erase/damage situation restoration of the databases is from a backup/restore capability  provided within the app.  Thus, I don't see a reason not to install the data files directly in Setup.
 
BTW, new users get the default files.  For users upgrading to the app from its previous version that had a different database structure, there is a first run capability to replace the default files with converted files from the previous version.  And, for future releases of the new app to existing users, data files will not be installed at all unless there are changes/additions to the database structure.
 
It's not that I refuse to look at your project.  It's a matter of thinking that using {commonappdata} in Inno Setup is a more direct and simpler way of establishing the location for the data files.  Perhaps I should ask the Inno Setup folks about the paths generated for each OS.  If {commonappdata} is not a reliable source for the paths I will certainly consider your project.

The user can affect the data. You probably just don't understand security. The app is under user control therefore it can only do what the user is allowed to do nothing else. If the user has privileges then the app has the same privileges, Not so dumb...
 
Perhaps the users data was erase, corrupted or damaged or you just wanted to start over. All you would need to do is to erase the data files in the  All users folder and new default files would be copied upon next run of the app. Installing them to that location would not allow you this option.
 
I gave you a project that would determine the correct folder for each OS but you refuse to even look at it. Understanding such issues as profiles would be done by running the app under different Windows version and all would be CRYSTAL CLEAR.
 
Testing is the way to verify hypothesis...

It's the user who is running the app so the app only has the privileges of the user.
 
Forgive the emotion but I think that's dumb.  If the user can't directly affect the data, why should the app be dependent on user privileges?  I can see user privileges affecting a user's ability to run the app but it seems to me that privileges to affect the data should be assignable to the app (and always be allowed).  But what is, is - so there's no point in further comment.
 
If the users will share the data you copy the files to All Users Application Data Profile.
 
As we've discussed, that is the case.  Forgive me if we've discussed this before but why have a first run situation where the app has to copy the data files - why can't they be installed by the Setup program to wherever they are to end up?
 
Either way, Profile is a new term to me.  I assume you are referring to the subfolders in Documents and Settings and I'm still not positive which these are for the different Win versions.  I assume that the path in Win2K and XP is Documents and SettingsAll UsersApplication DataAppNameDataFolder.  What about Vista?
 
Also, if the app has to create the AppNameDataFolder folder to do the first run copying, is there a Permissions situation?

No it does not change things... It's the user who is running the app so the app only has the privileges of the user.
 
1) No, this is what started all of this discussion about the limited user...
 
2) You can have the app place the data file in the {app} folder, This too we discussed. You want to install them there and upon first run copy the default files to each user if the users will not share the data. If the users will share the data you copy the files to All Users Application Data Profile.
 
3) The permissions are the same in all NT security operations.

After all the dialog we've had on install locations for app and data files, permissions, etc. I just thought of something that hasn't been focused on and may have a major impact on how I set up the installation:
 
USERS DO NOT DIRECTLY MODIFY THE DATA FILES.  All modifications are done BY THE APP based on user interaction with the app.  (For example, the user enters a score for a player; the app adds the score to the database.)
 
Does this change things?  
1) Can I just place the data files in a subfolder of the app's installation folder (Program FilesGHMGHMDATA)?
 
2) If so, can I (and how do I) specify things in Inno Script to do that and stay away from all the folders in Documents and Settings?
 
3) What are the Permissions implications in Win2K, XP and Vista, respectively?
 
With respect to 2) I'm thinking I can use my Template to directly specify the Destination Folder for the data files - DestDir: C:Program FilesGHMGHMDATA; Flags: ignoreversion uninsneveruninstall;

Yes, that is what I meant. I guess I got happy fingers on that one

In the first sentence of your last post I think you meant to say that you should only be able to modify folders under All Users that YOU CREATE (versus did not create).  That's consistent with the second sentence.

You should only be able to modify sub folders under the All Users folder that your did not create, that is what security is for. If you did not create the folder you should not have privileges in that folder unless explicitly given to you by the creator.

Now I'm really confused.  My small app does the following:
   -- Fills a variable AppDataPath with C:Documents and SettingsAll UsersApplication Data
   -- Makes a folder TESTDATA under AppDataPath
   -- Creates a file in the TESTDATA subfolder
   -- Writes some data to the file and closes it.
   -- Reopens the file and writes some changed data.
 
It works from the Limited account with no Permissions problems, and what I did did not involve setting permissions with the TweakHound method.
 
So what's confusing?  Well, I still can't add from the Limited account a text file via File/New/New Text Document to All Users or any of its subfolders except the new TESTDATA subfolder I created with the small app.  Why the difference with the small app?
 
I've also made some corrections in the use of the File System Object code in my main app - the code that overwrites the skeleton data files placed in the Documents and SettingsAll UsersApplication DataGHMDATA folder by Setup.  That works as well.
 
So, it looks like a have a solution but I don't know why!