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

"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.

In article ,
says...

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

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

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

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:

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

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

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

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)

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.

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

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.

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

In article ,
says...

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

??? I'm a retired programmer and what I always did since DOS3 was
determine where "exe"'s "home" folder was (param string 0 of command
line) when starting the program and all created files (e.g. ini and the
like) went there. No need for any registry entry once Windows came along
unless program had some "API" external sources could use.

I thought typically now programs made a folder under "My Documents" for
"transient" info. I sure have a few on every system I use. Seems to me a
"sane" method over scattering folders directly under "root".