I suppose notepad++ has a forum, but I wanted to check with you folks
first.

It works fine in the win10Home computer, and used to work fine in the
win10Pro computer. Since it broke, I've uninstalled and reinstalled it,
and now still, every time I close the program I get the same message
"ERROR OF SAVING SESSION XML FILE, C:\Programs\NotepadPP\session.xml"

And of course it doesn't save that file and doesn't load the old session
when I open again.

There is no file in the problem computer:
C:\Programs\NotepadPP\session.xml

Googling pointed to a user who had the ReadOnly bit set in C:\Programs\NotepadPP\session.xml. I don't even have that file but the directory itself has the Readonly bit set.

I'd like to unset the R, but in the other computer, that very directory
is also ReadOnly, and yet within it is that very file, session.xml which
was updated just an hour ago!!! Even though it's in a folder marked ReadOnly???????

Under Security/Permissions in the box that works, everything is
allowed for authenticated users except full control and special
permissions.
Under Permissions in the box that does not work, modify and write are
not permitted, even for authenticated users. This must be the
difference. (The rest is the same.)
Should I just check Modify and Write, in the Security tab of the Properties of the directory?
That will make it easier to change every file in the folder, but
aren't most program folders like that and most files don't get changed?

How do you suppose this difference began? Something I did? Sunspots?

Does it make sense to make a directory read-only and then give
permission to change it? Does't it confuse simple people like me?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2/6/2024 8:21 PM, micky wrote:

I suppose notepad++ has a forum, but I wanted to check with you folks
first.

It works fine in the win10Home computer, and used to work fine in the win10Pro computer. Since it broke, I've uninstalled and reinstalled it,
and now still, every time I close the program I get the same message
"ERROR OF SAVING SESSION XML FILE, C:\Programs\NotepadPP\session.xml"

And of course it doesn't save that file and doesn't load the old session
when I open again.

There is no file in the problem computer:
C:\Programs\NotepadPP\session.xml

Googling pointed to a user who had the ReadOnly bit set in C:\Programs\NotepadPP\session.xml. I don't even have that file but the directory itself has the Readonly bit set.

I'd like to unset the R, but in the other computer, that very directory
is also ReadOnly, and yet within it is that very file, session.xml which
was updated just an hour ago!!! Even though it's in a folder marked ReadOnly???????

Under Security/Permissions in the box that works, everything is
allowed for authenticated users except full control and special
permissions.
Under Permissions in the box that does not work, modify and write are
not permitted, even for authenticated users. This must be the
difference. (The rest is the same.)
Should I just check Modify and Write, in the Security tab of the Properties of the directory?
That will make it easier to change every file in the folder, but aren't most program folders like that and most files don't get changed?

How do you suppose this difference began? Something I did? Sunspots?

Does it make sense to make a directory read-only and then give
permission to change it? Does't it confuse simple people like me?

https://superuser.com/questions/1003703/windows-8-1-64-does-windows-redirect-writes-to-program-files-x86

"Found it - the answer is yes. Windows after UAC has a "VirtualStore"
where it keeps writes that 32 bit apps try to make to Program files.
It is a per-user store.

It is under your users folder, C:\Users\username\AppData\Local\VirtualStore .

Normally, Program Files is owned by TrustedInstaller. That's not a regular account.
It does not have a Home Directory. You can't log in as that account. However, it exists as a token that can be copied. To become that user (zen...), you copy a token from a program that has the ability to offer the token. That's
a service which is not normally running, and you manually start it and
copy the token. This "opens" the folder, and you "install" into it.

Once the install ceremony is over, stupid older programs try to
write their preferences in the Program Files. This does not represent installing. The program is not using the "install ceremony" to do it.
The program is using ordinary CreateFile/WriteFile to do stuff.
This is "not allowed" on the newer, more secure OSes.

To avoid havok, they make a VirtualStore feature, so the program thinks
it is writing there, and later attempts to access material written in there, magically succeed, even though they did not actually succeed. The material
was actually stored the whole time, in the "users VirtualStore folder".
Or, so it is claimed.

*******

Some of the if-then-else tree (stuff I'm not aware of), is here:

https://answers.microsoft.com/en-us/windows/forum/all/please-explain-virtualstore-for-non-experts/d8912f80-b275-48d7-9ff3-9e9878954227

"For a program to be eligible for virtualization, it must be 32bit,
not running with administrator rights and must not have been compiled
with a manifest file indicating it is for Vista or later.

You can see the virtualization status of a program by adding the
Virtualization column to the Processes page in Task Manager.

When a virtualized program attempts to write to a protected location
such as Program Files, Windows will intercept the access denied response
and redirect the write to C:\Users\<name>\AppData\Local\VirtualStore,
which is a hidden folder.

When a virtualized program attempts to read from a protected location,
Windows will first check for a copy of the file in VirtualStore. If it
finds it, it will use that copy. Otherwise it will attempt to read
from the original file.
"

You can see from that if/then/else, there are things a developer can
do, where the virtualization will be broken. By their stupidity :-)
This was only ever intended to help programs where the developer
is no longer available or interested in doing the maintenance.
That's why the helping hand is offered to 32-bit programs.

Paul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In alt.comp.os.windows-10, on Tue, 6 Feb 2024 22:09:45 -0500, Paul <nospam@needed.invalid> wrote:

On 2/6/2024 8:21 PM, micky wrote:

I suppose notepad++ has a forum, but I wanted to check with you folks
first.

It works fine in the win10Home computer, and used to work fine in the
win10Pro computer. Since it broke, I've uninstalled and reinstalled it,
and now still, every time I close the program I get the same message
"ERROR OF SAVING SESSION XML FILE, C:\Programs\NotepadPP\session.xml"

And of course it doesn't save that file and doesn't load the old session
when I open again.

There is no file in the problem computer:
C:\Programs\NotepadPP\session.xml

Googling pointed to a user who had the ReadOnly bit set in
C:\Programs\NotepadPP\session.xml. I don't even have that file but the
directory itself has the Readonly bit set.

I'd like to unset the R, but in the other computer, that very directory
is also ReadOnly, and yet within it is that very file, session.xml which
was updated just an hour ago!!! Even though it's in a folder marked
ReadOnly???????

Under Security/Permissions in the box that works, everything is
allowed for authenticated users except full control and special
permissions.
Under Permissions in the box that does not work, modify and write are
not permitted, even for authenticated users. This must be the
difference. (The rest is the same.)
Should I just check Modify and Write, in the Security tab of the
Properties of the directory?
That will make it easier to change every file in the folder, but
aren't most program folders like that and most files don't get changed?

How do you suppose this difference began? Something I did? Sunspots?

Does it make sense to make a directory read-only and then give
permission to change it? Does't it confuse simple people like me?

https://superuser.com/questions/1003703/windows-8-1-64-does-windows-redirect-writes-to-program-files-x86

"Found it - the answer is yes. Windows after UAC has a "VirtualStore"
where it keeps writes that 32 bit apps try to make to Program files.
It is a per-user store.

It is under your users folder, C:\Users\username\AppData\Local\VirtualStore .

I didn't really understand much of your post.

Normally, Program Files is owned by TrustedInstaller. That's not a regular account.

Are you saying I had to install in Program Files instead of Programs?
Because the one that works is installed in Programs, and so was the one
that doens't work, even when for a couple years until recently, it
worked fine.

I went ahead and added Modify permission to C:\Programs\NotepadPP. When
I checked Modify, Write became checked also. The 2 new checkmarks were
black, instead of grey like the original 3 were and remained. But the
program didn't work any better.

It does not have a Home Directory. You can't log in as that account. However, >it exists as a token that can be copied. To become that user (zen...), you copy
a token from a program that has the ability to offer the token. That's
a service which is not normally running, and you manually start it and
copy the token. This "opens" the folder, and you "install" into it.

Once the install ceremony is over, stupid older programs try to
write their preferences in the Program Files. This does not represent >installing. The program is not using the "install ceremony" to do it.
The program is using ordinary CreateFile/WriteFile to do stuff.
This is "not allowed" on the newer, more secure OSes.

To avoid havok, they make a VirtualStore feature, so the program thinks
it is writing there, and later attempts to access material written in there, >magically succeed, even though they did not actually succeed. The material >was actually stored the whole time, in the "users VirtualStore folder".
Or, so it is claimed.

*******

Some of the if-then-else tree (stuff I'm not aware of), is here:

https://answers.microsoft.com/en-us/windows/forum/all/please-explain-virtualstore-for-non-experts/d8912f80-b275-48d7-9ff3-9e9878954227

"For a program to be eligible for virtualization, it must be 32bit,
not running with administrator rights and must not have been compiled
with a manifest file indicating it is for Vista or later.

You can see the virtualization status of a program by adding the
Virtualization column to the Processes page in Task Manager.

When a virtualized program attempts to write to a protected location
such as Program Files, Windows will intercept the access denied response
and redirect the write to C:\Users\<name>\AppData\Local\VirtualStore,
which is a hidden folder.

When a virtualized program attempts to read from a protected location,
Windows will first check for a copy of the file in VirtualStore. If it
finds it, it will use that copy. Otherwise it will attempt to read
from the original file.
"

You can see from that if/then/else, there are things a developer can
do, where the virtualization will be broken. By their stupidity :-)
This was only ever intended to help programs where the developer
is no longer available or interested in doing the maintenance.
That's why the helping hand is offered to 32-bit programs.

Paul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Never mind. I just found that my file ssytem is all screwed up. It
will take at least an hour to put it right, tomorrow.

maybe after that things will work right.

In alt.comp.os.windows-10, on Tue, 6 Feb 2024 22:09:45 -0500, Paul <nospam@needed.invalid> wrote:

On 2/6/2024 8:21 PM, micky wrote:

I suppose notepad++ has a forum, but I wanted to check with you folks
first.

It works fine in the win10Home computer, and used to work fine in the
win10Pro computer. Since it broke, I've uninstalled and reinstalled it,
and now still, every time I close the program I get the same message
"ERROR OF SAVING SESSION XML FILE, C:\Programs\NotepadPP\session.xml"

And of course it doesn't save that file and doesn't load the old session
when I open again.

There is no file in the problem computer:
C:\Programs\NotepadPP\session.xml

Googling pointed to a user who had the ReadOnly bit set in
C:\Programs\NotepadPP\session.xml. I don't even have that file but the
directory itself has the Readonly bit set.

I'd like to unset the R, but in the other computer, that very directory
is also ReadOnly, and yet within it is that very file, session.xml which
was updated just an hour ago!!! Even though it's in a folder marked
ReadOnly???????

Under Security/Permissions in the box that works, everything is
allowed for authenticated users except full control and special
permissions.
Under Permissions in the box that does not work, modify and write are
not permitted, even for authenticated users. This must be the
difference. (The rest is the same.)
Should I just check Modify and Write, in the Security tab of the
Properties of the directory?
That will make it easier to change every file in the folder, but
aren't most program folders like that and most files don't get changed?

How do you suppose this difference began? Something I did? Sunspots?

Does it make sense to make a directory read-only and then give
permission to change it? Does't it confuse simple people like me?

https://superuser.com/questions/1003703/windows-8-1-64-does-windows-redirect-writes-to-program-files-x86

"Found it - the answer is yes. Windows after UAC has a "VirtualStore"
where it keeps writes that 32 bit apps try to make to Program files.
It is a per-user store.

It is under your users folder, C:\Users\username\AppData\Local\VirtualStore .

Normally, Program Files is owned by TrustedInstaller. That's not a regular account.
It does not have a Home Directory. You can't log in as that account. However, >it exists as a token that can be copied. To become that user (zen...), you copy
a token from a program that has the ability to offer the token. That's
a service which is not normally running, and you manually start it and
copy the token. This "opens" the folder, and you "install" into it.

Once the install ceremony is over, stupid older programs try to
write their preferences in the Program Files. This does not represent >installing. The program is not using the "install ceremony" to do it.
The program is using ordinary CreateFile/WriteFile to do stuff.
This is "not allowed" on the newer, more secure OSes.

To avoid havok, they make a VirtualStore feature, so the program thinks
it is writing there, and later attempts to access material written in there, >magically succeed, even though they did not actually succeed. The material >was actually stored the whole time, in the "users VirtualStore folder".
Or, so it is claimed.

*******

Some of the if-then-else tree (stuff I'm not aware of), is here:

https://answers.microsoft.com/en-us/windows/forum/all/please-explain-virtualstore-for-non-experts/d8912f80-b275-48d7-9ff3-9e9878954227

"For a program to be eligible for virtualization, it must be 32bit,
not running with administrator rights and must not have been compiled
with a manifest file indicating it is for Vista or later.

You can see the virtualization status of a program by adding the
Virtualization column to the Processes page in Task Manager.

When a virtualized program attempts to write to a protected location
such as Program Files, Windows will intercept the access denied response
and redirect the write to C:\Users\<name>\AppData\Local\VirtualStore,
which is a hidden folder.

When a virtualized program attempts to read from a protected location,
Windows will first check for a copy of the file in VirtualStore. If it
finds it, it will use that copy. Otherwise it will attempt to read
from the original file.
"

You can see from that if/then/else, there are things a developer can
do, where the virtualization will be broken. By their stupidity :-)
This was only ever intended to help programs where the developer
is no longer available or interested in doing the maintenance.
That's why the helping hand is offered to 32-bit programs.

Paul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

micky wrote:

Googling pointed to a user who had the ReadOnly bit set in C:\Programs\NotepadPP\session.xml. I don't even have that file but the directory itself has the Readonly bit set.

Are you sure about that?

Explorer can be confusing when looking at the read-only checkbox for a
folder, the checkbox is tristate (it can be unticked, ticked or
in-between) look very closely, it's only read-only it it *actually*
contains a tick.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2/6/2024 8:21 PM, micky wrote:

I suppose notepad++ has a forum, but I wanted to check with you folks
first.

It works fine in the win10Home computer, and used to work fine in the win10Pro computer. Since it broke, I've uninstalled and reinstalled it,
and now still, every time I close the program I get the same message
"ERROR OF SAVING SESSION XML FILE, C:\Programs\NotepadPP\session.xml"

And of course it doesn't save that file and doesn't load the old session
when I open again.

There is no file in the problem computer:
C:\Programs\NotepadPP\session.xml

Googling pointed to a user who had the ReadOnly bit set in C:\Programs\NotepadPP\session.xml. I don't even have that file but the directory itself has the Readonly bit set.

I'd like to unset the R, but in the other computer, that very directory
is also ReadOnly, and yet within it is that very file, session.xml which
was updated just an hour ago!!! Even though it's in a folder marked ReadOnly???????

Under Security/Permissions in the box that works, everything is
allowed for authenticated users except full control and special
permissions.
Under Permissions in the box that does not work, modify and write are
not permitted, even for authenticated users. This must be the
difference. (The rest is the same.)
Should I just check Modify and Write, in the Security tab of the Properties of the directory?
That will make it easier to change every file in the folder, but aren't most program folders like that and most files don't get changed?

How do you suppose this difference began? Something I did? Sunspots?

Does it make sense to make a directory read-only and then give
permission to change it? Does't it confuse simple people like me?

NotepadPP should be Notepad++

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

"...w¡ñ§±¤ñ " <winstonmvp@gmail.com> wrote

| Programs is subfolder of:
| C:\ProgramData\Microsoft\Windows\Start Menu\Programs
| It contains shortcuts to the executable in the Program Files and
| Program Files (x86 folder)

Whoa. Good catch. :)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In alt.comp.os.windows-10, on Wed, 7 Feb 2024 09:09:27 -0500, Zaidy036 <Zaidy036@air.isp.spam> wrote:

On 2/6/2024 8:21 PM, micky wrote:

I suppose notepad++ has a forum, but I wanted to check with you folks
first.

It works fine in the win10Home computer, and used to work fine in the
win10Pro computer. Since it broke, I've uninstalled and reinstalled it,
and now still, every time I close the program I get the same message
"ERROR OF SAVING SESSION XML FILE, C:\Programs\NotepadPP\session.xml"

And of course it doesn't save that file and doesn't load the old session
when I open again.

There is no file in the problem computer:
C:\Programs\NotepadPP\session.xml

Googling pointed to a user who had the ReadOnly bit set in
C:\Programs\NotepadPP\session.xml. I don't even have that file but the
directory itself has the Readonly bit set.

I'd like to unset the R, but in the other computer, that very directory
is also ReadOnly, and yet within it is that very file, session.xml which
was updated just an hour ago!!! Even though it's in a folder marked
ReadOnly???????

Under Security/Permissions in the box that works, everything is
allowed for authenticated users except full control and special
permissions.
Under Permissions in the box that does not work, modify and write are
not permitted, even for authenticated users. This must be the
difference. (The rest is the same.)
Should I just check Modify and Write, in the Security tab of the
Properties of the directory?
That will make it easier to change every file in the folder, but
aren't most program folders like that and most files don't get changed?

How do you suppose this difference began? Something I did? Sunspots?

Does it make sense to make a directory read-only and then give
permission to change it? Does't it confuse simple people like me?

NotepadPP should be Notepad++

It is that, but I'm not the only one who spells it even NPP. Finally
read their forum, and didn't find my problem but it led me to finding my screwed up directories. I don't rememeber doing this** or even when I
could have done it, but I copied a group of subdirectories to the wrong location, and now there are duplicates directory names. That couldn't
be helpful. **Based on the directory modified dates it was last
November 26th. Now, what was I doing that day? Actually, that was
well after when this notepad++ problem started, so maybe it's not the
problem, but I still have to correct it first.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2/7/2024 9:50 AM, micky wrote:

In alt.comp.os.windows-10, on Wed, 7 Feb 2024 09:09:27 -0500, Zaidy036 <Zaidy036@air.isp.spam> wrote:

On 2/6/2024 8:21 PM, micky wrote:

I suppose notepad++ has a forum, but I wanted to check with you folks
first.

It works fine in the win10Home computer, and used to work fine in the
win10Pro computer. Since it broke, I've uninstalled and reinstalled it,
and now still, every time I close the program I get the same message
"ERROR OF SAVING SESSION XML FILE, C:\Programs\NotepadPP\session.xml"

And of course it doesn't save that file and doesn't load the old session >>> when I open again.

There is no file in the problem computer:
C:\Programs\NotepadPP\session.xml

Googling pointed to a user who had the ReadOnly bit set in
C:\Programs\NotepadPP\session.xml. I don't even have that file but the
directory itself has the Readonly bit set.

I'd like to unset the R, but in the other computer, that very directory
is also ReadOnly, and yet within it is that very file, session.xml which >>> was updated just an hour ago!!! Even though it's in a folder marked
ReadOnly???????

Under Security/Permissions in the box that works, everything is
allowed for authenticated users except full control and special
permissions.
Under Permissions in the box that does not work, modify and write are >>> not permitted, even for authenticated users. This must be the
difference. (The rest is the same.)
Should I just check Modify and Write, in the Security tab of the >>> Properties of the directory?
That will make it easier to change every file in the folder, but >>> aren't most program folders like that and most files don't get changed?

How do you suppose this difference began? Something I did? Sunspots?

Does it make sense to make a directory read-only and then give
permission to change it? Does't it confuse simple people like me?

NotepadPP should be Notepad++

It is that, but I'm not the only one who spells it even NPP. Finally
read their forum, and didn't find my problem but it led me to finding my screwed up directories. I don't rememeber doing this** or even when I
could have done it, but I copied a group of subdirectories to the wrong location, and now there are duplicates directory names. That couldn't
be helpful. **Based on the directory modified dates it was last
November 26th. Now, what was I doing that day? Actually, that was
well after when this notepad++ problem started, so maybe it's not the problem, but I still have to correct it first.

You issued a command-line command, without putting double-quotes
around the "path with a space in the name". that's how it happened.

Paul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In alt.comp.os.windows-10, on Wed, 7 Feb 2024 18:21:53 -0500, Paul <nospam@needed.invalid> wrote:

On 2/7/2024 9:50 AM, micky wrote:

In alt.comp.os.windows-10, on Wed, 7 Feb 2024 09:09:27 -0500, Zaidy036
<Zaidy036@air.isp.spam> wrote:

On 2/6/2024 8:21 PM, micky wrote:

I suppose notepad++ has a forum, but I wanted to check with you folks
first.

It works fine in the win10Home computer, and used to work fine in the
win10Pro computer. Since it broke, I've uninstalled and reinstalled it, >>>> and now still, every time I close the program I get the same message
"ERROR OF SAVING SESSION XML FILE, C:\Programs\NotepadPP\session.xml"

And of course it doesn't save that file and doesn't load the old session >>>> when I open again.

There is no file in the problem computer:
C:\Programs\NotepadPP\session.xml

Googling pointed to a user who had the ReadOnly bit set in
C:\Programs\NotepadPP\session.xml. I don't even have that file but the >>>> directory itself has the Readonly bit set.

I'd like to unset the R, but in the other computer, that very directory >>>> is also ReadOnly, and yet within it is that very file, session.xml which >>>> was updated just an hour ago!!! Even though it's in a folder marked
ReadOnly???????

Under Security/Permissions in the box that works, everything is
allowed for authenticated users except full control and special
permissions.
Under Permissions in the box that does not work, modify and write are >>>> not permitted, even for authenticated users. This must be the
difference. (The rest is the same.)
Should I just check Modify and Write, in the Security tab of the >>>> Properties of the directory?
That will make it easier to change every file in the folder, but >>>> aren't most program folders like that and most files don't get changed? >>>>
How do you suppose this difference began? Something I did? Sunspots? >>>>
Does it make sense to make a directory read-only and then give
permission to change it? Does't it confuse simple people like me?

NotepadPP should be Notepad++

It is that, but I'm not the only one who spells it even NPP. Finally
read their forum, and didn't find my problem but it led me to finding my
screwed up directories. I don't rememeber doing this** or even when I
could have done it, but I copied a group of subdirectories to the wrong
location, and now there are duplicates directory names. That couldn't
be helpful. **Based on the directory modified dates it was last
November 26th. Now, what was I doing that day? Actually, that was
well after when this notepad++ problem started, so maybe it's not the
problem, but I still have to correct it first.

You issued a command-line command, without putting double-quotes
around the "path with a space in the name". that's how it happened.

Definitely worth considering. ... Okay I considered it and it's not too likely. I rarely use command-line commands and I never name anything
with a spece in the name (partly because it's hard for me to learn
something new, and partly because I don't want to bother with quotes.
And the directories that MS provided with spaces in the name, I avoid
using.

Paul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)