I have a VB 6 application that uses .mdb files via MDAC and installs with a standard setup.exe and cab file. I install the application on 64 bit Windows 7 professional in C:\program files (x86). This installs the exe, some dll files and a half dozen .mdb files. For various reasons related to testing, I need to replace the .mdb files selectively with other copies containing different data. However, when I do this and then run the application, it continues to find and use the original installed version of the files which I thought I'd replaced. Obviously it is using Windows file protection in some way. Is there any way to turn this off just for one file or folder but still leave it on for the drive as a whole? I am happy to have it turned on for the Windows system files for obvious reasons but just turn it off for selected files and folders. If this is the wrong forum, please let me know. Thanks!

Hi, Thanks for posting in Microsoft TechNet Forum. Based on my understanding, if this issue is caused by the Windows Resource Protection, you will get an "Access Denied" error, please check the properties of files: o Right-click the file whose properties you want to see, and then click Properties; o Keys that are WRP will show Trusted Installer with Full Control. SYSTEM, Administrators, and Users will only have Read permissions. If these files are protected by WPR, there is no way to disable Windows Resource Protection in Windows 7. If not, this would be related to the specific application, I suggest you post at Visual Basic forum for further help: Visual Basic Category Hope it helps. Alex Zhao TechNet Subscriber Support in forum. If you have any feedback on our support, please contact tngfb@microsoft.comPlease remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Alex, thank you for your response. I've changed the security for the files so that ordinary logged on users and administrators have full control and I am logged on as an administrator. The problem is related to Windows Restore points. Unfortunately, there does not seem to be any way to turn off Windows Restore at the folder level but only at the drive level. It is either ON for the whole drive or it is OFF for the whole drive. Even uninstalling and re-installing the software doesn't help. If I uninstall and then re-install, the files revert back to the versions that had been previously installed! Windows Restore is turning out to be pretty useless for anybody but simple users who never have any reason to use Windows Explorer to modify files outside of the My Documents folders. I suppose it could be useful if you are installing a piece of software you are not sure of and might want to revert back to before the software was installed. Other than that, it just seems to get in the way. This is not a VB issue but a Windows 7 issue. Thanks again.

I have now tried turning off System Restore but it makes no difference. I uninstall a program and then re-install it. The computer appears to be using a cached version of the previously installed files. I cannot get it to use the newly installed fresh version of the files. Similarly, if I copy versions of the files into the directory where they are installed, it continues to use a previous version that seems to be cached somewhere. Very strange.

Oh my God. I've just realized that the .mdb files installed with my application are protected by Windows Resource Protection and that there is no way to turn it off! Why on earth did Microsoft do this? I can understand doing this for system files but Applications need to be updated, have files swapped in and out - for example sample files, updates, and so on. Why on earth would Microsoft do something like this and not leave a way to at least create exceptions for application folders? What a bizarre and crippling feature. This will very severely limit my ability to support my customers as an application developer!

Hello, Are these files OS files or application specific files? File Protection in the OS only protects OS files, it also changed to protect with locked down permissions rather than file replacement. I would check the application for any cache locations or the path that is being used for otehr copies of the files.Thanks, Darrell Gorter [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights. VAMT - Volume Activation Management Tool - Download link http://www.microsoft.com/downloads/details.aspx?FamilyID=ec7156d2-2864-49ee-bfcb-777b898ad582&displaylang=en

Thanks for responding, Darrell They are application specific. I've just found that if I let Setup.exe install in the default directory ($AppPath) then everything goes into a C:\Program Files (x86)\AppName folder created during installation. Any files in there seem to be bird-dogged by WFP. If I try to replace my .mdb data files with, for example, sample files, the sample files are ignored and the original files are used by my app (a compiled VB6 exe file). However, if I install the application into a folder on the C drive that I create - say C:\appdir, then I can do whatever I want with the files. The reason I would tell my customers to do this is that I distribute updates of the exe and some .mdb files when I update the software. I just give them a web site to download the update files and let them know its available. There are over 100 customers all over the place using these apps and this is a serious problem. It looks like the solution might be to avoid c:\program files (x86) when installing apps that will be updated on Windows 7 machines. I have to say that if this is true it is quite restrictive and disappointing.

Hello, Since they are application files they would not be WFP protected. WFP only protects OS filesm it would not be protecting application files. Plus WFP no longer watches for directory change notifications, files are only replaced during repair or SFC operations, you may want to use something like Process Monitor from Sysinternals to watch what happens and where the mdb files are loaded from, I suspect the files are duplicated somewhere and being loaded from the other location or the application executable is located in multiple places and when started contains the mdb files in the same folder.Thanks, Darrell Gorter [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights. VAMT - Volume Activation Management Tool - Download link http://www.microsoft.com/downloads/details.aspx?FamilyID=ec7156d2-2864-49ee-bfcb-777b898ad582&displaylang=en

Darrell - great suggestion to use Sysinternals Process Monitor! Why didn't I think of this ? I installed Process Monitor and look what I found! Windows 7 seems to be maintaining copies of my application files in ... C:\Users\MyUserName\AppData\Local\VirtualStore\Program Files (x86)\MyAppName\MyDBFileName.mdb Where MyUserName is my Win 7 logon name, MyAppName is the Program Files (x86) folder in which my App is installed and MyDBFileName.mdb is the name of the Access/Jet database file. So, even if I de-install and re-install the application, virtual store is not cleared out and when I re-install, my program continues to use the copies of the file in the virtual store. If I open the virtual store file in Access it has data from the previous install! There is a very entertaining thread below about this in which a professional programmer (with whom I totally agree) rants about why this is a dumb idea and some other guy (with whom I disagree) rants back about Microsoft approved programming methodology, blah blah blah. http://answers.microsoft.com/en-us/windows/forum/windows_7-security/how-to-disable-virtualstore-in-windows-7/55dce284-0dcd-46af-892e-d2b9cf5bcff6?page=1 The suggestions made in this thread for disabling UAC, editing registry keys and taking full control of folders are completely impractical if you are distributing software to corporations who lock their machines down so that users cannot do this kind of thing - Sysadmins would go into full apoplexy at the very thought. One guy even suggested re-writing applications that are in wide distribution which is also completely impractical, not only in terms of the coding required but the logistics of updating and retraining existing users. And please, no lectures about Microsoft approved programming practices. Even those are contradictory, as a thread poster points out. One of the posters in this thread appears to be like myself - supporting an mdb file based app written many years ago (mine was written before SQL Server Express came along) and which is providing mission critical functionality to a wide user base. Fortunately, there seems to be a solution - just do not install applications to the Program Files (x86) folder ! No doubt Microsoft will find some way to kill this workaround too. When and if that happens, then the cost to my customers will be very high. I'm marking this post as the Answer myself - hope that's allowed.