File virtualization Windows 7

Question

4.00/5 (1 vote)

See more:

Hi all,

I have the following scenario...

For the club that I play contract bridge at I also manage the computer setup which is responsible for gathering scores from the score entry boxes and calculating scores at the end of a competition drive.

The program installed at this computer also holds the list of members of the club along with some address information such as email adresses etc.

To be able to send a club email to those people, I wrote a little program that accesses this member list and uses the emailaddresses to send the email. The member list lives inside an access database file (let's say Members.mdb, stored along with the program's installation folder under "Program Files").

Now comes the problem... Running this email program under Windows XP is not an issue at all. It opens the database, fetches the emailaddresses and send the emails. Recently, There was an upgrade to Windows 7. The score program runs like a breeze, but suddenly, the email sender program does not find the Members.mdb file anymore. THis turns out to be a feature called "File Virtualization", since the file still exists, but is placed in a different location (AppData....VirtualStore...Program Files...etc) This folder is however user specific, so should not be hardcoded ofcourse.

The question is: Is there a (standardized) way to access files that are supposed to be in the protected (Program Files) area, but were actually stored in their virtual counterpart folders under AppData? My selfwritten program goes to the actual Program Files folder, while the calculation program stores the file in the "virtualized" location.

Any help would be appreciated!

Regards, perry

Posted 12-Apr-11 10:03am

Perry Bruins

Add a Solution

2 solutions

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Espen Harlinn · Accepted Answer · 2011-04-12T10:32:00

Solution 1

Are you looking for Environment.GetFolderPath[^]?

Regards
Espen Harlinn

Posted 12-Apr-11 10:32am

Espen Harlinn

Comments

Nish Nishant 12-Apr-11 17:50pm

Good suggestion, voted 5.

Espen Harlinn 12-Apr-11 17:58pm

Thank you, Nishant!

Sergey Alexandrovich Kryukov 12-Apr-11 18:04pm

That simple suggestion is the most adequate, my 5.
--SA

Espen Harlinn 12-Apr-11 18:09pm

Thanks SAKryukov!

Perry Bruins 13-Apr-11 0:42am

I will have look at this one, if it works for my, I let you know and vote it 5. Thanks!

Espen Harlinn 13-Apr-11 8:45am

It will allow you to find the "correct" folder :)
As NTFS allows multiple directory entries, from multiple directories, to a single file there are some other options too

Perry Bruins 13-Apr-11 12:57pm

I actually tried this solution, but it still wants me to find out myself if "virtualization" is in effect or not, so this one does not work for me.

Espen Harlinn 13-Apr-11 14:04pm

Did you try Environment.GetFolderPath with SpecialFolder.ApplicationData?
SpecialFolder.ApplicationData specifies the directory that serves as a common repository for application-specific data for the current roaming user.
A roaming user works on more than one computer on a network. A roaming user's profile is kept on a server on the network and is loaded onto a system when the user logs on.
You have to append the relative path to the folder returened by Environment.GetFolderPath

Perry Bruins 14-Apr-11 1:51am

Hi Espen,

I actually saw that, but then my program still needs to find out or decide in some way that I need to go to the VirtualStore location and not the Program Files location. I was looking for an alternative where the system can decide that for me and the whole process becomes transparent. I decided to go with the solution as describes in Solution 2. Thanks for your thoughts though! Grtz, Perry

Nish Nishant · Accepted Answer · 2011-04-12T11:49:00

Solution 2

One hack-fix would be to run the old Score-app with UAC elevation - which means it will be able to read/write to the Program Files folder (which is what your app reads from).

[Edit]
--------

Follow-up to your comment.

Here your program is working correctly. It's the old program that is not. If you want identical behavior to the old program, compile your app as 32 bit and run it without UAC elevation and it will encounter virtualization too (like the older app).

Posted 12-Apr-11 11:49am

Nish Nishant

Updated 13-Apr-11 3:02am

v2

Comments

Espen Harlinn 12-Apr-11 17:58pm

Good point, 5ed!

Perry Bruins 13-Apr-11 0:41am

This is not what I want, I thought of this solution myself too. What I would like is that my program understands what to do when a situation like this arises, that is, work with UAC and deal with the situation at hand. Thanks for the suggestion though.

Nish Nishant 13-Apr-11 9:02am

Here your program is working correctly. It's the old program that is not.

If you want identical behavior to the old program, compile your app as 32 bit and run it without UAC elevation and it will encounter virtualization too (like the older app).

Perry Bruins 13-Apr-11 12:58pm

I'll go with this one since I do not see any alternatives at this moment. THanks for all your thoughts though!