[Geany-Devel] [Geany-devel] Remove MSYS dependency of Geany on Win~1 - VirtualStore data files

Matthew Brush mbrush at codebrainz.ca
Tue Dec 11 23:13:37 UTC 2012


On 12-12-11 09:44 AM, Nick Treleaven wrote:
> On 10/07/2012 12:55, Nick Treleaven wrote:
>>>> 2. A weird problem. Installing from cmd.exe doesn't overwrite
>>>> geany.glade (and maybe some other files) even though it appears to
>>>> succeed. I only noticed this because I'm missing the
>>>> View->Editor->Color
>>>> Schemes menu which was added about a month ago (I tend to test in place
>>>> rather than install each time).
>>>
>>> OMG... Then we must choose between copy and xcopy depending on which one
>>> works. Or we can define:
>>
>> Neither one works here ;-) But maybe it's something weird about my
>> system or because I previously installed using MSYS cp.
>
> OK, I think I finally found out whats happening here (or at least a
> related problem). Perhaps it will help someone else with the same problem.
>
> I was reluctant to delete the installed data files in case the problem
> was specific to them, but today I did, then reinstalled. The installed
> files all got the latest versions, but when I ran Geany the old data
> files were still being loaded (glade symbol errors, filetypes.common
> debug error message).
>
> So, I did a search for geany.glade and discovered it in:
> c:\Users\Nick\AppData\Local\VirtualStore\Program Files\Geany\data
>
> reading up on the VirtualStore path, I found it gets created when an
> application tries to write to a system path like Program Files, without
> the correct privileges. The application then silently receives the
> VirtualStore versions of files instead. I must have once tried to
> install geany without admin privileges, or manually copy over the data
> dir or something like that.
>
> This behaviour is really confusing if you're not aware of it. I think
> there is a way to tell Windows not to use VirtualStore for an specific
> application though, I'll have to look into it. In the meantime I just
> deleted the Geany dir under VirtualStore, all is now working correctly.

FYI, there was a related bug a while back about this:
https://sourceforge.net/tracker/index.php?func=detail&aid=3566329&group_id=153444&atid=787791

Cheers,
Matthew Brush


More information about the Devel mailing list