So I may have been a little hasty yesterday when talking about restrictive file access rights in Windows Vista. As it turns out there’s a mechanism that’s supposed to be able to work around these issues and it’s called folder virtualization.

The issue is that if you install into Program Files and you run as a non-admin account you won’t have write access to the files in your install folder. This is obviously a common thing for many applications that store their configuration data there as well as data.

I personally have always preferred installing data in a central location instead of plastering files all over your hard-drive which is what DLL and directory hell are all about. Nothing cleaner than a single directory install, right? Well, Vista doesn’t like it at least if you plan to run with a non-admin account.

So earlier today when I tried this virtualization did not work and that’s why I was having so much trouble with getting permission errors. I mucked around with my security policy setting (with gpedit.msc) a bunch and it’s possible that I enabled that feature and it’s disabled by default. I don’t know maybe somebody can check.

What this feature does is this: It detects any write access to a file by a user that doesn’t have rights to write to this file. It then makes a copy of the file in the user’s virtual store and happily allows the user to write to the file in the virtualized directory where the user has full rights.

What you see in this image are all the files that the application wrote to and made changes to which were then virtualized in this directory. The original files stay in the Program Files install folder.

That’s an impressive piece of architecture if you think about it, and it’s going to solve some problems with applications not having enough rights. It’s also useful for applications that never played well with multiple users – when turned on you get automatic user data separation for free.

Kinda confusing though. So I’m running Html Help Builder and it uses an INI file for a number of configuration settings. So I write out the config settings by saving from the Config dialog but the data doesn’t go into the .ini file in the install directory but the one in the virtual store. So if you ever look at the file in Program Files you're not going to see the same setting that the user just wrote.

Now if I log in as Administrator in turn though I do have rights to read the file from the original directory and now when I save it saves to program files. If I change the permissions in the program files directory and allow the non-admin user access to write it’s going to the Program Files directory again and it’s potentially shared. Looks like if the file exists in both locations the private virtualized location is used.

Brrrr… cool, but it can get confusing. So if you do want to share files in a single path for all users you have to be specific about it and give the appropriate users rights. Same if you want to share files over the network, but I suppose in that case a directory off the root is probably a better place for shared data.

Also as I mentioned yesterday the problem with WinZip actually turned out to be a problem with the WinZip self extractor which has lost its original command line interface. Once I ran the old version 2.x the Html Help Builder update (which is live now BTW for those of you that use Html Help Builder) worked.

As to installation I had to switch to an Admin user to install the application. For some reason Vista would not allow me to elevate to an Administrator in the existing session so I had to switch to my admin account, install, then come back and run Html Help Builder. I’m happy to report that once installed Html Help Builder ran Ok including building the help file and doing .NET imports (which is always a little tricky in terms of security).

I’m making headway, but I’m still a long way from getting this all dialed right. I’m not sure what the proper approach is for application installation and locations. I’ve been browsing around some of the Microsoft documents and they tell you a lot about what happens but not a lot about recommended approaches. <shrug>.