XP Security problem
-
We have a program that was written using Visual Basic, which has been working fine for 2 years on Win95/98/Me/NT4/NT2000. It does work properly when run on XP as anyone other than the adminstrator. The program generates a tab delimited file which stores user defined information as to how the software is to carry out some of its' taskes. How ever on XP when the user saves the data it is not saved, because the user does not have write pemission, in the directory where the program is located. How do I stop XP security from denying our software the right to update its' own data file. INTP
-
We have a program that was written using Visual Basic, which has been working fine for 2 years on Win95/98/Me/NT4/NT2000. It does work properly when run on XP as anyone other than the adminstrator. The program generates a tab delimited file which stores user defined information as to how the software is to carry out some of its' taskes. How ever on XP when the user saves the data it is not saved, because the user does not have write pemission, in the directory where the program is located. How do I stop XP security from denying our software the right to update its' own data file. INTP
XP and secure??? kewl... Don't try it, just do it! ;-)
-
We have a program that was written using Visual Basic, which has been working fine for 2 years on Win95/98/Me/NT4/NT2000. It does work properly when run on XP as anyone other than the adminstrator. The program generates a tab delimited file which stores user defined information as to how the software is to carry out some of its' taskes. How ever on XP when the user saves the data it is not saved, because the user does not have write pemission, in the directory where the program is located. How do I stop XP security from denying our software the right to update its' own data file. INTP
By default, users (i.e. accounts that are part of the Users group) are not allowed to write into the Program Files folder. You could make your users into Power Users (who do have permission), or you could change the permissions on the directory or, ideally, just the file so that the Users group has permission to write to this file. XP doesn't show the old security tab in the Properties box by default (when not connected to a domain) - to get it back, see http://www2.goldfisch.at/knowledge/241[^]. User preferences should really be stored in the registry or in the user's Local Settings or Application Data folders.
-
By default, users (i.e. accounts that are part of the Users group) are not allowed to write into the Program Files folder. You could make your users into Power Users (who do have permission), or you could change the permissions on the directory or, ideally, just the file so that the Users group has permission to write to this file. XP doesn't show the old security tab in the Properties box by default (when not connected to a domain) - to get it back, see http://www2.goldfisch.at/knowledge/241[^]. User preferences should really be stored in the registry or in the user's Local Settings or Application Data folders.
Thanks! The problem is that the User may be anyone that purchases our hardware (directly of indirectly). We (may) have no control of the End User and most of them may not even realize the file actualy exist. All the End User will know is that it did not save their information. The file could conceivably contain several hundred entries. INTP
-
Thanks! The problem is that the User may be anyone that purchases our hardware (directly of indirectly). We (may) have no control of the End User and most of them may not even realize the file actualy exist. All the End User will know is that it did not save their information. The file could conceivably contain several hundred entries. INTP
Hmm, in that case it sounds like a job for your setup tool. See the documentation for the
SetNamedSecurityInfofunction. Good coverage of security APIs in Programming Server-Side Applications for Windows 2000[^] and also in Programming Windows Security[^]. Specifically you need to give at least write access to the Users group. You'll need to look up the Security Identifier (SID) for the Users group on the local computer (seeLookupAccountName). However, your customer's administrator could potentially have renamed the Users group, in which case this won't work. A well-known SID such as the Authenticated Users or Interactive SID might work better. Please tell me you're not using the Package and Deployment Wizard :wtf: - it's rather painful to add a custom install step, IIRC. -
Hmm, in that case it sounds like a job for your setup tool. See the documentation for the
SetNamedSecurityInfofunction. Good coverage of security APIs in Programming Server-Side Applications for Windows 2000[^] and also in Programming Windows Security[^]. Specifically you need to give at least write access to the Users group. You'll need to look up the Security Identifier (SID) for the Users group on the local computer (seeLookupAccountName). However, your customer's administrator could potentially have renamed the Users group, in which case this won't work. A well-known SID such as the Authenticated Users or Interactive SID might work better. Please tell me you're not using the Package and Deployment Wizard :wtf: - it's rather painful to add a custom install step, IIRC.Thanks! It looks like I now have a better chance at solving the problem. No I am not using the Package and Deployment Wizard. "Live long an prosper." INTP
-
Hmm, in that case it sounds like a job for your setup tool. See the documentation for the
SetNamedSecurityInfofunction. Good coverage of security APIs in Programming Server-Side Applications for Windows 2000[^] and also in Programming Windows Security[^]. Specifically you need to give at least write access to the Users group. You'll need to look up the Security Identifier (SID) for the Users group on the local computer (seeLookupAccountName). However, your customer's administrator could potentially have renamed the Users group, in which case this won't work. A well-known SID such as the Authenticated Users or Interactive SID might work better. Please tell me you're not using the Package and Deployment Wizard :wtf: - it's rather painful to add a custom install step, IIRC.Mike Dimmick wrote: it's rather painful to add a custom install step, IIRC :eek: :wtf: Please don't remind me of the nightmare :(( I'm still trying to forget the horror :omg: Paul ;)
Garfield.Bark(); **---Configuration: garfield - Win32 Deworm---** C:\garfield.cpp(9) : error C2039: 'Bark' : is not a member of 'CCat'