Page 1 of 1

windows virtualstore

Posted: Fri Oct 30, 2015 10:30 am
by John
Has anyone else enocunted the windows virtualstore yet?

It seems that sometimes Windows 7 and higher likes to make copies of your stuff and put it there... then redirect BR's access to those files instead. Sometimes I find this makes my updates not work... because some or all of a previous update is in there and this update just updated the regular files.

Has anyone else encountered this yet? It's happened to me a couple times now.

-John

Re: windows virtualstore

Posted: Fri Oct 30, 2015 4:57 pm
by Susan Smith
John,

When this happens to you, what is the intended destination of those files? Does the user have write permissions there? I have heard lots of complaints about Windows Virtual Store from other people (non-BR folks). And for myself, I have had all sorts of WB files put there with no rhyme or reason, most notably spool files. I DO have a designated place where spool files are supposed to go, but they still end up in virtual store every once in a while. The same occasionally happens with files from Atlantis, MyEdit and Foxit PDF Reader and even Adobe common files. I understand that Windows Virtual Store is an attempt to redirect files from being written to places where Windows thinks you don't have Admin privileges when you need them. But I also find that it isn't reliable. Why do SOME spool files end up there and not others? Why do MyEditBR error logs sometimes end up there, but not always? I'm not changing my installation, so I don't know what the inconsistency is.

Are the files that you are dealing with NEW ones or existing files that are being updated. Is it consistent as to WHAT files are ending up there? You might try deleting them from the Virtual Store and seeing if files are recreated there going forward just to test.

I know that you can stop the behavior in Vista by turning off UAC, but that doesn't work in later versions of Windows. I think you have to reassign permissions on a folder-by-folder basis, which is a pain if you are trying to do automated installs and updates.

I'm sorry. It's a pain when Windows thinks it knows more about your software and how it should work than you do. On the other hand, a lot of us do not use the Windows user profile folder structure to our advantage either (like for user-based ini files and temp files in the appropriate places), so perhaps that gets us into trouble.

-- Susan

Re: windows virtualstore

Posted: Sat Oct 31, 2015 12:38 pm
by John
Intended destination is usually C:\Program Files (x86)\ACS 5\*etc*
The users usually do not have write permissions there. However the installer is supposed to elevate the rights as necessary. ... :idea: perhaps there is a command line (or SYSTEM) parameter that will allow me to run the update execuatable as an administrator. hmmmm...

I've read that windows puts files there when a program tries to write files to a folder it does not have permission to write to. I suppose that would be okay, if it'd continue to do it forever for eternity, but when later updates come along and work fine they are left using the old version of those programs. And that's the problem.

I agree about it being very inconsistent. I am considering doing a check for files in the virtural store... but I'm not sure if detecting and deleting things in the virtural store is really the right route to go... maybe a detect and warn and ask them to call support... hmmm... :?:

I *THINK* I am using the windows folder structure properly - I now keep my data files in %programdata%\ACS\*etc*, my program files in the Progam Files (x86)\ACS\*etc* and now I've even started running in the *temp* folder as a working directory so indexes (which to the current working directory) do not fail due to rights issues. Perhaps you should do the same for your spool issues. It took me a few days (weeks if you count the data) of coding to change all my programs to access everything with virtural paths and for it to auto set up those virtural drive paths after launching. But it was totally worth it! I have to very little manual setup in brconfig.sys when deploying a system and things just work. I only have to set up one drive statement. and often a WBServer and Set Env (for Data). I keep those in an included file so I can automatically update the brconfig.sys itself.

Re: windows virtualstore

Posted: Sat Oct 31, 2015 1:11 pm
by Susan Smith
That is some really good advice, John. I have temp files created all over the place because I would revise things in current programs or change my mind for NEW sub-systems and never take the time to go back to the old programs to make everything consistent. This is particularly true when I make a copy of a data file before running a procedure (so that I can get it back if the procedure fails). I would be much better off putting ALL temp files of every kind in a temp folder and keep the folders much more cleaned up. I will think about this and see if I can figure out how much of a job that this might entail. Thanks for the idea.

-- Susan

Re: windows virtualstore

Posted: Sat Oct 31, 2015 2:09 pm
by bluesfannoz
If your going to use Program files then all users will have to have full control in that folder or windows is going to use the virtual store as Program Files is a OS restricted folder. We chose not to place ours there, that being one of many reasons we chose not to. Its also a good idea to make one of the users that has full access the owner of the folder.

Re: windows virtualstore

Posted: Mon Nov 02, 2015 8:06 am
by John
Steve,
I have been using the Program Files folder for a several years now. I only keep my actual program files there. I use INNO Setup Installer for my updates and it ask for elevated rights as necessary. I've only encountered the virtural store problem twice. It may have been a bug in an earlier version of INNO setup.
Lately, I've encountered another issue - indexes create a temporary file in the working directory - there is no way to change it. When you don't have rights to your working directly the index command basically kills the indexes and wipes them clean. So what I did about that was to start using the Temp directory as my working folder. It means that everything has to be references with full paths instead of realtive, but with some dynamic drive statements:

Code: Select all

04030   let fn_map_to_virtural_drive(os_filename$(''),'R:')

36000   def fn_map_to_virtural_drive(path_to_map$*256,drive_id$*2)
36020     execute 'config drive '&drive_id$(1:1)&','&rtrm$(path_to_map$,'\')&',X,\' ioerr ignore
36040   fnend 
and then adding an R:\ to all of my program file references I was able to make it work and totally sidestep needing to run my indexes from a special directory... I just run everything from TEMP and even very old programs tried to make stuff in the current directory now work without a hitch.

-John

Re: windows virtualstore

Posted: Mon Nov 02, 2015 8:27 am
by Gabriel
Lately, I've encountered another issue - indexes create a temporary file in the working directory - there is no way to change it.
Have you tried specifying a WORKPATH in your brconfig.sys file?

That specifies the path that BR uses for all temp files, including the files used for creating indexes.

Lots of people specify it for other reasons, for example to increase performance when running over a network by configuring the clients to use a local drive or even a RAM-disk for the temp work files. It seems like the same thing would help in your situation.

Add a line that says something like:

WORKPATH %temp%

to your BRConfig.sys file.

http://brwiki2.brulescorp.com/index.php?title=WORKPATH

Gabriel

Re: windows virtualstore

Posted: Mon Nov 02, 2015 10:33 am
by John
I'm pretty certain I tried WorkPath - I have some notes about it and I worked with Gordon on the issue. I tested with it again, but wasn't able to reproduce the origional index issue on my test system, but I added in a workpath %temp% anyway - just because it might help some workstation speed issues a couple users experience. Good tip!

Re: windows virtualstore

Posted: Thu Apr 28, 2016 9:46 am
by John
Gabriel wrote:
Lately, I've encountered another issue - indexes create a temporary file in the working directory - there is no way to change it.
Have you tried specifying a WORKPATH in your brconfig.sys file?
Oh by the way - I figured out a solution to this. It took a bit of work but I made my software start in the program directory, but then immediately change to the tempory directory and work from there. I just had to make all of my file access be complete paths instead of being relative to my working directory. I made this work with environment variables and BR Virtual Drives. I still run into programs attempting to access data without a full path, but at least all my index statements work.

Re: windows virtualstore

Posted: Thu Apr 28, 2016 10:10 am
by Gabriel
I'm glad you got it working. But I'm sorry it was so tricky.

That sounds like a very complicated solution for what should be a simple problem.

Gabriel