If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
|
Thread Tools | Rate Thread | Display Modes |
#1
|
|||
|
|||
Program doesn't have permission in program files folder?
I got a program that's been on my system for ages, and recently it
stopped working and started giving me errors. First error it displays right after it starts up is that it couldn't open up its help file. The second error occurs after I try to open up any saved databases for this program. When I try to open the database, it announces that it's attempting to create a new config file (something like: "creating new config file C:\Program Files (x86)\Yadayada\...\wfg.cfg") followed immediately by the announcement that it failed to create that file. It sounds to me like the permissions in the "program files (x86)" folder have gone awry. What permissions and ownerships should I check for? Yousuf Khan |
Ads |
#2
|
|||
|
|||
Program doesn't have permission in program files folder?
"Yousuf Khan" wrote in message ... I got a program that's been on my system for ages, and recently it stopped working and started giving me errors. First error it displays right after it starts up is that it couldn't open up its help file. The second error occurs after I try to open up any saved databases for this program. When I try to open the database, it announces that it's attempting to create a new config file (something like: "creating new config file C:\Program Files (x86)\Yadayada\...\wfg.cfg") followed immediately by the announcement that it failed to create that file. It sounds to me like the permissions in the "program files (x86)" folder have gone awry. What permissions and ownerships should I check for? Yousuf Khan I think the first thing I'd try is uninstalling and re-installing the program. |
#3
|
|||
|
|||
Program doesn't have permission in program files folder?
|
#4
|
|||
|
|||
Program doesn't have permission in program files folder?
On 14/10/2014 3:37 PM, Dave-UK wrote:
I think the first thing I'd try is uninstalling and re-installing the program. Already done, same thing. Yousuf Khan |
#5
|
|||
|
|||
Program doesn't have permission in program files folder?
On 14/10/2014 3:38 PM, pjp wrote:
I had that problem trying to get Delphi 7 running under Win 7. When I looked online it seemed that it wasn't possible. It is though, just select the "Program Files\Borland" folder and change the permissions so everyone could do whatever to it and presto compiler and IDE runs fine. I was hoping to avoid that, but it looks like it's only way. I hope it doesn't set me up for some nasty security hole in the future. Yousuf Khan |
#6
|
|||
|
|||
Program doesn't have permission in program files folder?
On 10/14/2014 4:46 PM, Yousuf Khan wrote: On 14/10/2014 3:38 PM, pjp wrote: I had that problem trying to get Delphi 7 running under Win 7. When I looked online it seemed that it wasn't possible. It is though, just select the "Program Files\Borland" folder and change the permissions so everyone could do whatever to it and presto compiler and IDE runs fine. I was hoping to avoid that, but it looks like it's only way. I hope it doesn't set me up for some nasty security hole in the future. Yousuf Khan You could install it to a folder in the root of C: |
#7
|
|||
|
|||
Program doesn't have permission in program files folder?
Yousuf Khan wrote:
I got a program that's been on my system for ages, and recently it stopped working and started giving me errors. First error it displays right after it starts up is that it couldn't open up its help file. The second error occurs after I try to open up any saved databases for this program. When I try to open the database, it announces that it's attempting to create a new config file (something like: "creating new config file C:\Program Files (x86)\Yadayada\...\wfg.cfg") followed immediately by the announcement that it failed to create that file. It sounds to me like the permissions in the "program files (x86)" folder have gone awry. What permissions and ownerships should I check for? Yousuf Khan The Program Files tree is owned by TrustedInstaller account. And rather than being a conventional account (one you could log into), it's a "service". This is part of "hardening" the OS, to prevent exploits. You're not supposed to write, as an application, into the Program Files folder tree. Such behavior is deprecated. For compatibility, Microsoft re-directs attempts to write the Program Files folder, to a "Roaming" folder in your own AppData area. While it may look like the database file is sitting in the Program Files folder, it's actually in your own Roaming folder. Now, suspecting all of this, I have no idea how to help you :-( Is the problem a problem with permissions on the Roaming folder ? Is the problem with TrustedInstaller service ? I haven't a clue. And if you've been messing about, changing the ownership of Program Files folder yourself, I'm similarly out of ideas how to fix it. Many people mess around with this stuff, but I'm sure the vast majority, never put things back the way they were in the first place. So once you start playing whack a mole, busting stuff, you're on your own. Paul |
#8
|
|||
|
|||
Program doesn't have permission in program files folder?
On 14/10/2014 7:25 PM, Paul wrote:
The Program Files tree is owned by TrustedInstaller account. And rather than being a conventional account (one you could log into), it's a "service". This is part of "hardening" the OS, to prevent exploits. You're not supposed to write, as an application, into the Program Files folder tree. Such behavior is deprecated. For compatibility, Microsoft re-directs attempts to write the Program Files folder, to a "Roaming" folder in your own AppData area. While it may look like the database file is sitting in the Program Files folder, it's actually in your own Roaming folder. Now, that's starting to make some sense now. I have recently moved my own user account's entire user tree to the D: drive, because C: drive was getting filled up. After moving my user account to the D: drive, I also created a directory junction between the old C: drive location and the new D: drive location, just for any programs that might still expect things to appear in the old location, though all of the environment variables are now properly set to point to the D: drive. I wonder if the permissions and ownership in the D: drive are not properly set yet? Now, suspecting all of this, I have no idea how to help you :-( Is the problem a problem with permissions on the Roaming folder ? Is the problem with TrustedInstaller service ? I haven't a clue. And if you've been messing about, changing the ownership of Program Files folder yourself, I'm similarly out of ideas how to fix it. I haven't actually changed any of the ownership in the Program Files yet, though I was just about to just before I read this, and it set me thinking again. Many people mess around with this stuff, but I'm sure the vast majority, never put things back the way they were in the first place. So once you start playing whack a mole, busting stuff, you're on your own. Yeah, I've gone through this sort of issue in the past too, that's why I was hesitant. I'm not going to do it now. But I do need to find about ownerships in the User folders. Yousuf Khan |
#9
|
|||
|
|||
Program doesn't have permission in program files folder?
| I haven't actually changed any of the ownership in the Program Files
| yet, though I was just about to just before I read this, and it set me | thinking again. | If you're worried about security you don't necessarily need to change permissions on the whole program folder. Just change them on the folder where the file needs to be written. Installing to another location wouldn't make things any safer. Either way that folder will need permissions changed. |
#10
|
|||
|
|||
Program doesn't have permission in program files folder?
On Tue, 14 Oct 2014 18:09:35 -0500, Bob I wrote:
On 10/14/2014 4:46 PM, Yousuf Khan wrote: On 14/10/2014 3:38 PM, pjp wrote: I had that problem trying to get Delphi 7 running under Win 7. When I looked online it seemed that it wasn't possible. It is though, just select the "Program Files\Borland" folder and change the permissions so everyone could do whatever to it and presto compiler and IDE runs fine. I was hoping to avoid that, but it looks like it's only way. I hope it doesn't set me up for some nasty security hole in the future. Yousuf Khan You could install it to a folder in the root of C: Just to add a small voice: I made a folder C:\Programs (Other) I put a few programs in there because they misbehave in the standard folders. I chose that name only to make it sort near Program Files and Program Files (x86) Two programs in there are 40tude Dialog and Eclipse. -- Gene E. Bloch (Stumbling Bloch) |
#11
|
|||
|
|||
Program doesn't have permission in program files folder?
On Tue, 14 Oct 2014 19:25:57 -0400
Paul wrote: You're not supposed to write, as an application, into the Program Files folder tree. Such behavior is deprecated. I was not aware of this, although I should have been. I'm an amateur VB6 programmer. Every program I have written keeps any data and/or config files in its own folder tree under Program Files. Now I am going to have to do a rewrite on any of them that I want to run on Win7. I guess I will have to move things to the AppData tree. Thanks Paul. As always, you are a fountain of knowledge. -- Wildman GNU/Linux user #557453 Jeff Foxworthy's Redneck Dictionary asinine, adj. I give her face a 7 and her asinine. |
#12
|
|||
|
|||
Program doesn't have permission in program files folder?
| You're not supposed to write, as an application, into the
| Program Files folder tree. Such behavior is deprecated. | | I was not aware of this, although I should have been. | I'm an amateur VB6 programmer. Every program I have | written keeps any data and/or config files in its own | folder tree under Program Files. I've done the same thing. Most older software did. The switch to AppData is only partly for security reasons. (How many malware are going to get on a machine and then raise havoc by corrupting software, after all?) The bigger reason is because Microsoft's main customer is corporate business, where all PCs are actually workstations. Each workstation is used by one or more employees who are not allowed to access anything but their own personal folders and are not allowed to do anything but their assigned work. Storing all data in App Data or My Documents allows multiple users on such a workstation who all see the same program but each with their own personal settings. When Vista/7 came out I looked into the options. One problem for me was that I don't write software for workstations. I write it for and sell it to individuals. In most cases different settings for different people are not going to make sense. The software is normally used by one person. In the occasional case where Dad shows Junior how to use the software it's going to be better if Junior is using it with Dad's settings. I also wanted people to be able to find their settings as easily as possible for purposes of backup. In addition to the App Data change, Windows virtualization was throwing a wrench into the works. Depending on permissions and UAC settings it was difficult to know exactly where a file might *really* be. Adding to that, the Registry HKLM key could no longer be written to in most cases. My own solution was to just stay contained and avoid the restrictions mess altogether, like a portable app. I now have my installer create a subfolder in the program folder. Into that folder I put two other folders: settings and temp. Each of those is set with no restrictions. I can then store settings locally and do file operations without worrying that Windows restrictions might screw things up. At the same time, my method is secure. The executables in the program are still in a restricted folder. The settings files are just plain text. If you use the PDW you might find this useful: http://www.jsware.net/jsware/vbcode.php5#set12 I rewrote the PDW to remove a couple of bugs, cut down on the bloat and eliminate the need for setup.exe. The result is about half the original size and has added functions for setting folder permissions, as well as for creating shortcuts. Setup.exe was outdated. Microsoft had it doing some funky prep work, but its main function was to install the runtime on older machines before running setup1.exe, which needs the runtime. These days all machines have msvbvm60.dll and the COM libraries, so it made sense to just move the odds and ends duties on setup.exe into setup1.exe and get rid of setup.exe altogether. |
#13
|
|||
|
|||
Program doesn't have permission in program files folder?
On 14/10/2014 11:33 PM, Gene E. Bloch wrote:
Just to add a small voice: I made a folder C:\Programs (Other) I put a few programs in there because they misbehave in the standard folders. I chose that name only to make it sort near Program Files and Program Files (x86) Two programs in there are 40tude Dialog and Eclipse. Interesting idea. |
#14
|
|||
|
|||
Program doesn't have permission in program files folder?
On 15/10/2014 1:39 AM, Wildman wrote:
On Tue, 14 Oct 2014 19:25:57 -0400 Paul wrote: You're not supposed to write, as an application, into the Program Files folder tree. Such behavior is deprecated. I was not aware of this, although I should have been. I'm an amateur VB6 programmer. Every program I have written keeps any data and/or config files in its own folder tree under Program Files. Now I am going to have to do a rewrite on any of them that I want to run on Win7. I guess I will have to move things to the AppData tree. Thanks Paul. As always, you are a fountain of knowledge. Well, you may not have to, as Paul said, Windows is supposed to automatically redirect writes to the AppData folders anyways. Yousuf Khan |
#15
|
|||
|
|||
Program doesn't have permission in program files folder?
|
|
Thread Tools | |
Display Modes | Rate This Thread |
|
|