I have an application that write data in the programdata folder in vista. The application seems to write data to that location but the folder is not visible. What will be the problem for this.
Vista virtualizes directories that you don't have access to write to (ie C:\Program Files). So:
C:\Program Files\Your Program\Your File.txt
becomes:
C:\Users\You\AppData\Local\Virtual Store\Program Files\Your Program\Your File.txt
This is a new security feature to Vista, which has a lot of benefits, but it means you'll need to do a little more to make your app work correctly with vista.
See this
Program Data folder is one of Vista's forbidden zones administered by Windows Resources Protection mechanisms. If you value a stable operating systems, don't play with this folder.
See About Windows Resource Protection.
By default this folder is hidden.
Related
I have a Visual Basic 6.0 application that I want to install for All Users, for example, the setting are held in a single spot regardless who logs into the computer. I have the following code to locate the common location:
Const ssfCOMMONAPPDATA = &H23
Dim strAllUsersPath As String
strAllUsersPath = CreateObject("Shell.Application").NameSpace(ssfCOMMONAPPDATA).Self.Path
On Windows XP, this path points to C:\Documents and Settings\All Users\Application Data\ folder. The setup copies the settings file there and everything is great. The Visual Basic 6.0 app can change it at any time.
On Windows 7, this path points to c:\ProgramData folder. The setup, which requires administrator privileges, copies the file there. However, when my Visual Basic 6.0 application starts and accesses the file, Windows 7 copies the settings file to a C:\Users{USER LOGIN}\AppData\Local\VirtualStore\ and performs all the operations on it there. As a result, because for each user, Windows 7 copies the settings file to a separate user directory, the users end up having a different settings file.
Am I storing the file in the wrong location? Am I doing it in the incorrect manner?
This one has bitten me too. The ProgramData folder has shared Read Access, no shared write access. You can of course change the permission on the folder during install, but I think that goes contrary to how Microsoft meant it to be.
See this other question for some useful links
How Microsoft thinks it should be done.
I am using Delphi 7 on Windows 7 and have an application which uses a TFileListBox component to iterate through files in a directory and copies them to a backup directory.
I'm experiencing some strange behavior whereby the TFileListBox is detecting files which do not exist within the directory?? The directory I am coping from contains 75 files but the TFileListBox detects over 100 files.
I changed my explorer settings to display hidden/system files but still cannot see where these extra files are coming from.
I was wondering whether this Windows 7 Previous Versions was playing a part in this problem as I am fairly sure that the extra files the TFileListBox is detecting did used to once reside in this directory but were deleted...
Any help on this would be much appreciated.
We have worked out from the comments above that the issue is related to the Virtual Store which is used when your application is virtualized. The virtual store was introduced with Windows Vista as part of the move to running applications without administrator rights. These files are appearing in the virtual store because your application is writing to the program files directory, to which standard users do not have write privileges.
Virtualization was introduced to help deal with legacy applications that were not going to be recompiled to take account of the new Vista policies. Nowadays you simply should not be building a virtualized application.
You can disable virtualization by linking an application manifest to your application that includes the <requestedExecutionLevel level="asInvoker"/> section.
When you do this, you will no doubt find some other problems because your application may attempt to write to the program files directory, the HKLM section of the registry, etc. Whilst it may seem painful to make these changes, they are worth the effort.
Until Windows Vista I saved my application data into the directory where the program was located. The most common place was "C:\Program Files\MyApplication". As we know, under Vista and later the common user does't have rights to write under "Program Files" folder.
So my first idea was to save the application data under the "All Users\Application Data" folder. But it seems that this folder has writing restrictions too!
So to sum up, my requirements are:
The folder should exist under Windows XP and above.
All users of the system should have read\write\creation rights to this folder and its subfolders and files.
I want to have only one copy of file\files for all users.
It's often good to use environment variables so you keep things more generic.
Vista has changed some things, with NTFS Junction Points. See http://www.svrops.com/svrops/articles/jpoints.htm
Anyway, using %appdata% should automagically put files in the proper place on xp/vista/7
There is no such location. Even on Windows XP (and probably 2000 as well) no such location ever existed; we just think it did because we all ran with administrative privileges. It is not until Vista forces us to run as limited user that we realize our incorrect assumptions. You're going to have to explicitly set the permissions on your directory.
I would create a subfolder like All Users\Application Data\YourAppName\Shared, so that it's clear that just that folder will contain files writeable by all the users, setting up the privileges in the installer.
I have a setup project that installs my app to the typical program files directly.
My app periodically saves some temporary images to the apps installation folder. It seems on Vista, the permissions are not setup for write permissions. I can change it manually in windows explorer and it works, but I would rather have the setup project do that automatically.
How can I do this?
Is there a better/more normal place to put temp images that won't have permissions issues?
It is not Vista specific, this will happen with any kind of user account that doesn't have admin privileges. Your program just can't write to folders like c:\program files\blah. That UAC disables admin privileges has been publicized for a long time now. Use Environment.GetFolderPath() to get the path to an ApplicationData folder that you can write to.
See http://msdn.microsoft.com/en-us/library/bb756940.aspx for details on UAC issues for vista. These problems can also occur in other versions of windows when running applications from non-admin accounts. You should only write data to app data or temp directories and not program files.
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.
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.
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.
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.
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