I bought a laptop from a store a week ago, and it was their demo, so
they probably had some security on it to keep customers from messing
it up.

All of the folders seem to have the "read only" property grayed out,
and I can't change it. I go through the process to change it, but it
doesn't change. The problem is that files can't be written to the
proper folder. For instance, a program in \ProgramFiles\MyFolder that
wants to write to that folder instead writes to
\users\username\AppData\local\VirtualStore\Program Files\MyFolder.

I created a new user with admin rights, and told it to make everything
not read only. For several minutes it went through the process of
marking all of the folder properties, but it still has the same
problem.

As a last resort, I think I can use the CDs to restore it to the
factory settings, and that might fix the problem. But is there a
better way to fix the problem?
--
Replace you know what by j to email

Take it back to the store.

"Jud McCranie" <youknowwhat.mccranie@adelphia.net> wrote in message

> But is there a
> better way to fix the problem?
> --

There's about 9.5 Million responses to a google query about this.

Short version - the read only attribute does not affect folders. You can't
change it, it doesn't do anything. Forget about it, go play some freecell.




"Jud McCranie" <youknowwhat.mccranie@adelphia.net> wrote in message
news:j286g39uk55hale3bfkb8atk1q459oba9j@4ax.com...
I bought a laptop from a store a week ago, and it was their demo, so
they probably had some security on it to keep customers from messing
it up.

All of the folders seem to have the "read only" property grayed out,
and I can't change it. I go through the process to change it, but it
doesn't change. The problem is that files can't be written to the
proper folder. For instance, a program in \ProgramFiles\MyFolder that
wants to write to that folder instead writes to
\users\username\AppData\local\VirtualStore\Program Files\MyFolder.

I created a new user with admin rights, and told it to make everything
not read only. For several minutes it went through the process of
marking all of the folder properties, but it still has the same
problem.

As a last resort, I think I can use the CDs to restore it to the
factory settings, and that might fix the problem. But is there a
better way to fix the problem?
--
Replace you know what by j to email

"Jud McCranie" <youknowwhat.mccranie@adelphia.net> wrote...
> All of the folders seem to have the "read only" property grayed out,
> and I can't change it. I go through the process to change it, but it
> doesn't change. The problem is that files can't be written to the
> proper folder. For instance, a program in \ProgramFiles\MyFolder that
> wants to write to that folder instead writes to
> \users\username\AppData\local\VirtualStore\Program Files\MyFolder.

As Val remarked, this is normal behaviour. To amplify a bit, on that ...

The "Read-only" property on directories is a hold-over from DOS and Windows
3.x days. It doesn't have any effect at all on whether you can read or write
to a directory, on any version of the NT operating system (including here,
Windows NT, Windows 2000, Windows XP, Windows Server 2003, Windows Vista and
Windows Server 2008). Instead, these operating systems use Access Control
Lists ("ACLs"), to control who has access to files and directories. Because
it is a useless appendix, the Explorer shell uses the "read-only" bit to
control some behaviour about whther file icons will be displayed over a
network. It has nothing whatever to do with file permissions.

The behaviour you are seeing is normal in Vista. The directory tree under
"C:\Program Files" is protected - you cannot write data to these
directories. Writing to these locations was a favourite attack vector for
viruses and trojans. Storing user data in these directories has been
deprecated as a bad programming practice for many years; applications should
write to the %ProgramData% directory, or to locations under the user's
profile. Because some old applications continue to try to write to locations
under C:\Program Files, Vista uses "virtualisation" to redirect the write
operation to a safe location. This is described in the following Mcrosoft
KnowledgeBase article:

http://support.microsoft.com/kb/927387/en-us

Your program that tries to write to "C:\Program Files\MyFolder" is obsolete,
it uses long-deprecated practices. It should be updated to fit in with
Vista's security requirements (however it will continue to run as-is on
Vista, albeit with virtualisation in effect).

Hope it helps,

--
Andrew McLaren
amclar (at) optusnet dot com dot au

"DP" <nospam@nospam.com> wrote in message
news:%233PJ9wXBIHA.912@TK2MSFTNGP05.phx.gbl...
> Take it back to the store.
> "Jud McCranie" <youknowwhat.mccranie@adelphia.net> wrote in message
>> But is there a
>> better way to fix the problem?
>> --



Wow...clueless!

Honu

On Wed, 3 Oct 2007 16:29:12 +1000, "Andrew McLaren"
<andrew@fakeaddress.com> wrote:

>As Val remarked, this is normal behaviour. To amplify a bit, on that ...

....

>Your program that tries to write to "C:\Program Files\MyFolder" is obsolete,
>it uses long-deprecated practices. It should be updated to fit in with
>Vista's security requirements (however it will continue to run as-is on
>Vista, albeit with virtualisation in effect).
>
>Hope it helps,

Yes, it helps very much. You are the first one to explain it so it
well enough and completely so that it makes sense, thanks. The
program is this one: http://www.mersenne.org/freesoft.htm which hasn't
been updated since August 2005.
--
Replace you know what by j to email

"Jud McCranie" <youknowwhat.mccranie@adelphia.net> wrote...
> well enough and completely so that it makes sense, thanks. The
> program is this one: http://www.mersenne.org/freesoft.htm which hasn't
> been updated since August 2005.

Ahhh! That would explain why we're running low on prime numbers, lately :-)

The "write" permission problem probably only affects prime.ini (and
primnet.ini, if you have one, to configure the proxy server).

The virtualised copy of the ini files in
\users\username\AppData\local\VirtualStore\Program Files\Prime95 should
continue to work normally; so I expect Prime95 will run normally. The
"virtualisation" is supposed to be fairly transaprent to the user (that was
the intention, anyway).

But if it really bugs you, you can change the permissions on the "real"
prime.ini file in Program Files, to make it read/write. The program can then
use the "real" prime.ini instead of the virtualised on over in
AppData\local\VirtualStore

To do this, right-click C:\Program Files\Prime95\prime.ini, and choose
Properties, from the context menu. The prime.ini properties panel will
appear. Click on the Security tab. The ACL editor will appear, where you
change who has permission to write to the file. You will see that "Users"
probably have only Read and Read/Execute permissions. Click on the Edit
button, and change the permissions for Users to "Full Control". Click OK to
save changes. You will now be able to read *and* write to the file. Once
this is enabled, Windows will let Prime95 use the "original" copy under the
"Porgram Files" directory; and ignore the vitualised copy under
AppData\local\VirtualStore (you may need to manually copy the changes to the
virtualised copy across to the original copy, to bring them into sync).

In the late 1990s, I had Prime95 running on a "massive" Digital Alpha
Server, 24x7 for about 3 years. We never found a Mersenne prime, but it
served as a kind of "pet" for the team ... we'd arrive at work in the
morning and go to see if it had found any numbers, overnight :-) Actually
that "massive" server is probably equivalent to a modest Celeron processor,
today ... but it was good at the time.

Maybe Gorge Woltman will update Prime95 for Vista some day. At the moment
you cannot run it from bootup, as a service, either; because Vista doesn't
allow services which interact with the desktop (also for security reasons).
The last I checked, the code was also highly optimised to run on a single
processor; which is no longer a valid assumption today, even many laptops
have Core Duo 2 processors.

Good luck with the prime-hunting!

--
Andrew McLaren
amclar (at) optusnet dot com dot au

On Thu, 4 Oct 2007 08:23:29 +1000, "Andrew McLaren"
<andrew@fakeaddress.com> wrote:

>The "write" permission problem probably only affects prime.ini (and
>primnet.ini, if you have one, to configure the proxy server).

There are also the Pxxxx and Qxxxx data files, and WhatToDo and
Results.txt. In fact, it was the results.txt file that alerted me to
the issue. (I've been using Vista less than a week.) I ran a
benchmark but the results.txt file wasn't where it was supposed to be.
I did a Search and found it in the VirtualStore.


>The virtualised copy of the ini files in
>\users\username\AppData\local\VirtualStore\Progra mFiles\Prime95 should
>continue to work normally; so I expect Prime95 will run normally.

It is running normally, just that files aren't were they would
normally be.

>In the late 1990s, I had Prime95 running on a "massive" Digital Alpha
>Server, 24x7 for about 3 years. We never found a Mersenne prime, but it
>served as a kind of "pet" for the team ... we'd arrive at work in the
>morning and go to see if it had found any numbers, overnight :-) Actually
>that "massive" server is probably equivalent to a modest Celeron processor,
>today ... but it was good at the time.

I've been in the project nearly 10 years. When I started, exponents
were under 700,000 and tests on an original Pentium took about 10
hours.

>Maybe Gorge Woltman will update Prime95 for Vista some day. At the moment
>you cannot run it from bootup, as a service, either;

Yes, that is mentioned on the download page.

>The last I checked, the code was also highly optimised to run on a single
>processor; which is no longer a valid assumption today, even many laptops
>have Core Duo 2 processors.

I have a dual CPU desktop, and I run two instances. There is no
benefit to two CPUs on one instance.
--
Replace you know what by j to email

"Jud McCranie" <youknowwhat.mccranie@adelphia.net> wrote...
>>The "write" permission problem probably only affects prime.ini (and
>>primnet.ini, if you have one, to configure the proxy server).
>
> There are also the Pxxxx and Qxxxx data files, and WhatToDo and
> Results.txt. In fact, it was the results.txt file that alerted me to
> the issue. (I've been using Vista less than a week.) I ran a
> benchmark but the results.txt file wasn't where it was supposed to be.
> I did a Search and found it in the VirtualStore.

Doh, yes of course ... I forgot about those.

You can also mark the whole Prime 95 directory read-write for Users, using
the same method (right click, ACL editor). That would solve the problem for
all files in a single stroke (slightly less secure, but you may choose to
decide it's a reasonable compromise).

--
Andrew McLaren
amclar (at) optusnet dot com dot au