The application I am working with writes to the User\Application Data folder on XP and the AppData\Roaming folder on Vista. On one of the Vista machines the AppData\Roaming folder is not present. As a result some of the features of the application are not functioning.
Have any of you encountered such a scenario before? I am not sure what to do in this case. Can I create the AppData\Roaming folder?
Thanks
jbsp72
If you're hardcoding those paths, you should be using environment variables instead.
On the machine in question, open a command prompt (WinKey+R>cmd>Enter) and enter echo %appdata% and press Enter. It should return the application data path for the current user.
...oh, and to use environment variables, replace, for example c:\Program Files\MyProgram\data with %programfiles%\MyProgram\data
There are many lists of these available, on of which is at http://vistaonwindows.com/environment_variables.html
Related
A windows 2000 computer running Terminal Service creates a temporary folder for each terminal session, and it appends the hexadecimal value to the temporary folder name depicted by the environment variable %TEMP%.
Reference
Terminal Services Temporary Folder Configuration Is Stored in Multiple Registry Locations
Temporary Folders
Use separate temporary folders for each session
My Question is does %TMP% also behaves in the similar manner as %TEMP% or it refers to a different location (the parent directory of %TEMP%).
Note I know people would tend to say that this question is related to SU but I am trying to use the Environment Variables in my program as a temporary store. So that makes it a programming question. Problem is that as TEMP folder is deleted once the user logs of this creates issues causes services to crash. Ok I understand this is not a good solution to use temporary store but we just looking for a short term solution until we come up with something better.
TorgoGUy Have answered a question similar to this:
What's the difference between %TMP% and %TEMP% in Vista environment variables?
It is for compatibility. It goes all the way back to DOS. Since there
were no standards, some DOS (and Win 3.x) applications would look for
the %TMP% environment variable and others would look for %TEMP%. You
were best off if you set both of them in the AUTOEXEC.BAT file.
Windows NT set both of them automatically just to make sure all of the
apps continued to work OK. %TEMP% is the standard now, but %TMP% lives
on.
And Yes both variables %TMP% & %TEMP% point to the same location %WinDir%\Temp\
Hope this helps.
I have created a small exe and associated ini file that we use for diagnostics on customers sites. Customers can go to our website, run a configuration program which downloads the diagnostic exe and ini and sets the exe running.
We do not want to go through a full Windows installation for this as this is overkill for the customers who just want something that will load and start running in 10-15 seconds.
Where should we download this exe to and run according to Windows philosophy and where it is guaranteed to work? The following conditions are essential:
A customer doing this may be an administrator on the machine but may also be a basic user.
UAC may be switched on.
Also during the course of the procedure the user might change.
The exe also needs to be able to write to its ini when it first starts.
The OS could be XP, Vista, Win7 32-bit, Win7 64-bit
If there is one folder that covers all of the above then fantastic but I'd also be happy to use an appropriate different folder for each of the OS's named.
In the folder pointed by %APPDATA% environment variable which is inside the user profile directory (%USERPROFILE%), if it is supposed to be used by any user then %ALLUSERSAPPDATA% which is inside %ALLUSERSPROFILE%
Take a look at Recognized Environment Variables
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.
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
On OS from win 2000 or later (any language) can I assume that this path will always exists?
For example I know that on win xp in some languages the "Program Files" directory have a different name.
So is it true for the System32 folder?
Thanks.
Ohad.
You definitely cannot assume that: Windows could be installed on a different drive letter, or in a different directory. On a previous work PC Windows was installed in D:\WINNT, for example.
The short answer is to use the API call GetSystemDirectory(), which will return the path you are after.
The longer answer is to ask: do you really need to know this? If you're using it to copy files into the Windows directory, I'd suggest you ask if you really want to do this. Copying into the Windows directory is not encouraged, as you can mess up other applications very easily. If you're using the path to find DLLs, why not just rely on the OS to find the appropriate one without giving a path? If you're digging into bits of the OS files, consider: is that going to work in future? In general it's better to not explicitly poke around in the Windows directory if you want your program to work on future Windows versions.
No, you can't assume that.
Windows can be installed to a different path. One solution is to look for it by calling GetSystemDirectory (implemented as part of the Windows API).
Windows can be installed on a different harddrive and or in a different folder. Use the %windir% or %systemroot% environment variables to get you to the windows folder and append system32. Or use the %path% variable, it's usually the first entrance and the preferred method of searching for files such as dlls AFAIK. As per comments: don't rely too much on the system32 dir being the first item. I do think it's safe to assume it's in %path% somewhere though.
I would use the GetWindowsDirectory Win32 API to get the current Windows directory, append System32 to it an then check if it exists.
It might be safer to use the "windir" environment variable and then append the "System32" to the end of that path. Sometimes windows could be under a different folder or different drive so "windir" will tell you where it is.
As far as i know, the system32 folder should always exist under the windows folder.
Just an FYI, but in a Terminal Server environment (ie, Citrix), GetWindowsDirectory() may return a unique path for a remote user.
link text
As more and more companies use virtualized desktops, developers need to keep this in mind.