views:

413

answers:

4

We have a program that the installer checks for the existence of a config file, and if it exists, it doesn't copy that file over (it assumes the user has modified their config file and wants to keep those modifications). Unfortunately, this is a pre-Vista application and it keeps the config file in Program Files. The problem is, if you manually wipe out the directory when it re-installs certain API still thinks that there is a directory there. VB6, for example, and its browse for file dialog sees the folder, however explorer, cmd shell, etc cannot see folder. Writing over the file still leaves the old file there (to some API's, but not to explorer) which cannot be removed except form within the Browse for File dialog.

What is going on with these Phantom folders, and how do we delete the file so that all API's see the same thing? Maybe it has something to do with TxF, or the indexer for search, but both the installer we use (InnoSetup) and parts of the application (the parts written in VB6) are seeing the old version of the file, and everything else sees the current version.

A: 

Do you mean the AppData folder (C:\Documents and Settings\UserName\AppData)? I'm not on my vista machine, but I think that's the path, and afaik it's not wiped after an uninstall.

SnOrfus
Nothing to do with AppData, it has to do with %ProgramFiles% (C:\Program Files) and how Vista handles it. For many reasons we can't move the config into AppData where it should be.
Kris Erickson
+5  A: 

Dunno if I'm on the right track, but doesn't Vista virtualize %programfiles% for applications that tries to write to it or otherwise are flagged as "not going about this the right way"? (and hence moves it somewhere into the user part of the filesystem instead, without telling the legacy app about it - making it kinda transparent)..?

Virtual Store Redirected files are stored somewhere in %appdata% - you can also find out the location by checking the "Compability Files" option in Explorer when at the aliased location. You need to stop writing to %programfiles% to get rid of this behaviour as far as I know.

Oskar Duveborn
Yes, I think you are on the right track, but where is that User Part of the file system?
Kris Erickson
+5  A: 

As Oskar Duveborn said, it's very likely that what you're seeing is Vista's virtualization behaviour.

When a machine has User Account Control (UAC) enabled, standard users and non-elevated programs aren't allowed to write to the Programs folder. Windows instead silently redirects files to the appropriate subfolder of %AppData%\Local\VirtualStore (for example, C:\Users\MyUser\AppData\Local\VirtualStore).

If you browse the real folder in Explorer, you'll see the 'Compatibility Files' toolbar button, which you can use to browse the virtual store instead.

Note that this is only compatibility behaviour from Windows - your program should write to its own subfolder of %AppData%.

For more information, see this TechNet Magazine article.

Ant
A: 

The TechNet link by Ant above (accepted answer) is no longer valid. The new link is:

http://support.microsoft.com/kb/927387 - Common file and registry virtualization issues in Windows Vista