Question

Submitted for your approval, a story about a poor little java process trapped in the twilight zone…

Before I throw up my hands and just say that the NTFS partition is borked is there any rational explanation of what I am seeing. I have a file with a path like this

C:\Program Files\Company\product\config\file.xml

I am reading this file after an upgrade and seeing something wonky. Eclipse and my Java app are still seeing the old version of this file while some other programs see the new version. The test that convinced my it was not my fat finger that caused the problem was this:

In Explorer I entered the above path and Explorer displayed the old version of the file. Forcing Explorer to reload via Ctrl-F5 still yields the old version. This is the behavior I get in Java. Now in PowerShell I enter

more "C:\Program Files\Company\product\config\file.xml"

I cut and past the path from Explorer to make sure I am not screwing anything up and it shows me the new version of the file.

So for the programming aspect of this, is there a cache or some system component that would be storing this stale reference. Am I responsible for checking or reseting that for some class of files. I can imagine somebody being “creative” in how xml files are processed to provide some bell or whistle. But it could be a case of just being borked.

Any insights appreciated…Thanks!

Answer 1

That’s due to UAC virtualization. The extra files thatyou see live in C:\Users\<USER>\AppData\Local\VirtualStore\Windows. That got introduced in Vista. More info can be found at Microsoft Technet.

You can also get to the ghost version of the file by browsing to c:\program files in Explorer and then clicking “Compatibility files”.