Windows Vista Virtual Store
Vista has a security "feature" that locks down certain system folders (for instance Program Files) from programmatic modifications. However, it doesn’t just deny your IO requests; instead it may or may not redirect it to some virtual store elsewhere on the file system (it’s per-user too, so that could further screw your code up if you were writing out something global or machine-wide). The best part is you don’t know if you were redirected or not. I’ve had it where I was being redirected to the virtualized location for writes and then when I attempted to read later, it wouldn’t redirect me and I would be reading from the real Program Files. Another odd thing is that it appeared to always read and write from the real Program Files location if the context was that of a locally-hosted web site.
Here’s another blogger’s discovery of it for further information: http://www.hanselman.com/blog/VistasShowCompatibilityFilesAndTheScrumptiousWonderThatIsFileVirtualization.aspx
I don’t know why I didn’t know anything about this until now, but I quickly learned about .NET’s Isolated Storage APIs. Pretty useful for persisting configurations and such. It was the solution to my problem in this case. Here is a good article on it: http://www.developer.com/net/net/article.php/3430541
I will warn you though that you should try to do the reading and writing from the same assembly from within the same application; otherwise, you end up getting different isolated storage stores for each call. According to the many documents I read there is a way to call into a certain store even if .NET doesn’t normally map your assembly and/or application to that location (you have to provide something called Evidence). I couldn’t get it to work and was running short on time.
