External lexers - VirtualStore - and plugins config files in general

gstavi

The following investigation was done with my lexamples plugin for Makefile lexing but it applies for other lexers and plugins configuration in general.

External lexer comes with xml file that contains the language styles. This xml can be placed in one of 2 places:

Users\username\AppData\Roaming\Notepad++\plugins\Config
Program Files\Notepad++\Plugins\config

Problem with option 1: Does not work for multi user systems. During plugin installation this location can only be set for current user. When another user launches Notepad++ the xml file will not be found and Notepad++ will disable the lexer plugin.
Problem with option 2: User should not be able to write to this location so user cannot modify the styles for the language.

However, option 2 does work. Thanks to Microsofts VirtualStore. When one modifies the style the file is written to:
Users\username\AppData\Local\VirtualStore\Program Files\Notepad ++\Plugins\Config

The problem is that VirtualStore is a stupid idea that should only be used to workaround issues of legacy unsupported applications that cannot be fixed. Even advanced users will have hard time realize that something wrong comes from that place. I spent about an hour until I realized where the lexer configuration is actually written to.

Notepad++ is supported, it should not need VirtualStore.

Try this:

Start Notepad++
Write some garbage into a new document.
Save it as aaa.txt into Notepad++ directory or even Program Files directory.

Expectation is to get access denied which will cause you to choose proper directory. But if VirtualStore is enabled on your machine, file will be written to it, you will never realize that you did something stupid, and will not fix your (mental) bugs.

Do yourself a favor and disable VirtualStore using registry:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
EnableVirtualization=0
Reboot is required. Don’t worry it does not disable ‘Virtualization’ your VMs are safe.

However, once VirtualStore is disabled we realize that there is a bug. If Notepad++ reads xml from location 2, then it also tries to save modifications into location 2. And fails silently without an error or a warning. When Notepad++ is restarted the modified styles are gone.

Not sure why Notepad++ should ever modify files in location 2. I realize that there were lots of discussions about it and it may be applicable for installations outside “Program Files” but Notepad++ should prefer location 1 or at least fallback to it once writing to location 2 fails.

Alan Kilborn

@gstavi

Very clear explanation.
Create a N++ issue on github and paste it there?

Ekopalypse

@gstavi said in External lexers - VirtualStore - and plugins config files in general:

Problem with option 1: Does not work for multi user systems. During plugin installation this location can only be set for current user. When another user launches Notepad++ the xml file will not be found and Notepad++ will disable the lexer plugin.

I would say, check in the setInfo callback if the lexer xml is present and act accordingly.

I agree that attempts should be made to write to APPDATA if the first attempt in Program Files fails, but how did it happen to be available there in your example?

gstavi

@Ekopalypse said in External lexers - VirtualStore - and plugins config files in general:

but how did it happen to be available there in your example

I wrote this lexer 7 years ago. I have been using it with older npp version I didn’t bother to update. Meanwhile all kind of changes happened in Notepad++ configuration schemes I did not bother to follow closely.

For some reason, early this week I updated my code to compile with newer npp. I realized that the old plugin package does not install the xml file into the (new) correct place so I tried to figure out what is the correct place while copying the xml file manually.

Initially I identified the problem with multi user install where notepad++ shows a message of “xml not found” and was about to file a bug for that. But after phrasing the ticket I suddenly thought that maybe I did not place the xml in the right place in Notepad++ directory and found out that placing it in plugins/config does work for multi users.

Then I tried changing the style and see if Notepad++ saves a copy of the xml into APPDATA. It did not but Notepad++ magically remembered the modification anyway. That driven me nuts. It took me an hour to find out the modified file in VirtualStore and a few more hours of googling on what it is and how to disable it.

Ekopalypse

@gstavi said in External lexers - VirtualStore - and plugins config files in general:

I see.

It took me an hour to find out the modified file in VirtualStore and a few more hours of googling on what it is and how to disable it.

Luckily you explained it very well so I didn’t have to deal with it :-D

gstavi

Out of curiosity, browse your VirtualStore and share with us information of which files ended up there.

Ekopalypse

@gstavi

Nothing from Npp, probably as I’m using portable version always.

Program Files: Oracle (virutalbox) and ImageMagick
Program Files (x86): THQ, Steinberg, Power Tab, PDFCreator, Motorola, MetzUpdater, Cypheros, avicohh