Yahoo messenger and Windows VirtualStore
Today I had an interesting challenge in front of me. As I already wrote about in a couple of posts I have a NAS set up for backing up my personal data, as well as my important VMWare machines. I switched my Windows backup client to Cobian last week, because GFI has serious issues with task scheduling. Now I am trying Cobian to see how it will do. So I added the folders, than need to be backup-ed, to the backup plan in Cobian. One of the folders is a Yahoo messenger archive folder for my profile. I use YM for day to day work, because I work from home and it is my link with my coworkers through the day. I store every conversation to the archive, so I have a complete history in case I need some info about app design or anything else, that was decided a while ago and it is not in the mail.
Ok so what did I find out? YM tries to store the profile and archives into the “Program Files (x86)\Yahoo!\Messenger\profiles” folder (I have 64 bit Windows 7). Well Windows VirtualStore kicks in at that moment, redirecting all the data to the “Users\UserName\AppData\Local\VirtualStore\Program Files (x86)\Yahoo!\Messenger\Profile”. I know why MS implemented VirtualStore. User apps have no business writing data to the “Program Files”. But guess what, they do. And a lot of them, even popular apps like YM. And because MS wanted better security and on the same side wanted old apps to continue running, they made the decision about VirtualStore. But I don’t think it was a smart one. Redirecting data to some obscure path, deep into the user profile is not a good idea. Redirecting to a path that has hidden folders in it is even worse idea. People then don’t know what happened with their data and that can lead to data loss or some irrational decision made in panic that also lead to data loss.
Lets take my case for example. Under Windows XP, my archive was written to “Program Files”. After installing Windows 7, I restored to the previous state ,installing YM again. I could see my archived data when I checked if it was there in YM. But from then on all the data was written to the VirtualStore, without me being aware of it. When I restored my backup plan I was missing all the new data recorded after the transition to Windows 7. And I am a developer, so I quickly found that out, when restoring the backup plan. But what about the common user, that has no way of knowing that and resolving such issues. I think a better approach would be:
- Let the application crash if it tries to write to “Program Files”
- Explicitly tell the application to work in “Windows XP” compatibility
- VirtualStore is disabled when applications are run in compatibility mode
Yes, it would be harder for the user in the beginning, but they would quickly learn how to handle legacy apps and application developers would have to fix their applications. And because the message would be clear: “Your app is not working correctly”, a user would be aware of the error instead of having the illusion that all is well.
So how did I solve the problem. I made a NTFS Junction Point. The procedure is simple:
- I moved the complete archive from “Program Files” and VirtualStore to my actual profile folder: “Users\UserName\AppData\Local\Yahoo\Profiles“
- I deleted the old archive locations and I also deleted the profile folder in YM “Program Files” directory
- I opened CMD and typed: mklink /D /J “C:\Program Files (x86)\Yahoo!\Messenger\profiles” “c:\Users\UserName\AppData\Local\Yahoo\Profiles”
That is it. Now YM thinks it is writing and reading data from “Program Files” but instead it is doing it from my user profile folder. I made YM do what it should in the first place and worked around VirtualStore. It is an interesting solution that could come handy in many other cases. And for those of you out there wondering: “Did he use the latest YM?” Yes I installed the latest YM before doing anything else. Version 10 still writes to the “Program Files” and I can’t understand why haven’t they fixed that.
I know many will disagree with my view on this topic, but as I see it, this is how things stand right now 
Warren wrote,
Virtual Store will make IT people, and ordinary computer users scratch their heads, pull out their hair, and scream.
So would crashing applications, but at least the crashing application failure is noisy, and can be fixed (by people who are not afraid to modify file system write permissions). This failure is silent, until your data is gone.
Imagine you save your file, then open it from another application, with the same absolute location (“C:\foo\bar\bat.txt”) and depending on which application you open it with, you get two completely different file content, or two almost identical files, with different content.
It’s an IT nightmare.
W
Link | February 1st, 2010 at 8:33 pm
Mike Dixon wrote,
I agree that the VirtualStore has been a nightmare, but it’s one of the ways to ensure legacy apps still run after an upgrade.
There are other ways around it, such as not installing to Program Files, or changing the permissions on that apps folder before running it.
I don’t agree with the premise that apps should not write to Program Files. I have several apps that I can just backup their entire folder and the app can be moved to another computer (no dependent files). Having the app files in one place and data in another is retarded sometimes.
For example, what if I want to distribute a database that the user will then be able to modify. I have to jump through hoops to copy it to somewhere else and so forth.
My apps folder should belong to my app.
Link | February 1st, 2010 at 10:25 pm
Iztok Kacin wrote,
@Mike
Application wide settings and other application wide (or should I say computer wide) data can be in Program Files. But user data can’t. The whole idea of profiles is to make them private to the user. They have to tasks.
1. To protect the data from other users
2. To make the data user specific
If everything would be in the Program Files then users could not have their separate data. Ok it could be solved with user specific subfolders (mini profiles per application), but then you have an even greater fragmentation of data and even more problems with security.
The model itself regarding the separation of data is good, but the VirtualStore implementation is not. Otherwise we seem to agree that VirtualStore is more of a manace than actual help.
Link | February 2nd, 2010 at 8:36 am