I want to allow all users to read and write in a file, through my application. The file is common to all users. Where should I put that file in Windows 7?
You can use the Known Folders.
If users don't need to see the files the you can use:
FOLDERID_ProgramData - default location will be "c:\ProgramData"
If the user needs to be able to browse and find the file then the "Public" user can be used. Either FOLDERID_Public or FOLDERID_PublicDocuments. That will default to "c:\users\Public*"
You can check the list of all the standard Known Folders to see if there is anything that would work better for you. This page has the same list with friendly descriptions on how they should be used.
Use the function SHGetKnownFolderPath to get the path on the current system. Don't assume the default values are valid.
If you need this to run on Windows XP then use the previous function SHGetFolderPath and equivalent CSIDLs.
Related
We currently have a legacy solution (on Windows) where the source code cannot be changed, and it is hard-coded to use paths in a specific location \\Server1\folderA for example on really old servers where data-content is stored.
We now have new servers that we want to use instead to hold our data content, but cannot update the hard-coded paths in the legacy solution to use these directly.
Is there anyway to use an alias, or a redirection from one fileserver to another, so that when something tries to get data content from path \\Server1\folderA it gets redirected over to \\Server2\folderB for example and therefore uses the files on the new server?
Thanks
I think I have found a solution to my own problem:
Open a Command Prompt with Administrator privileges and use the following command:
mklink /d \\Server1\folderA \\Server2\folderB
I was going through the source code of a rainmeter skin and i could not understand :
TextShortcut1=Computer
TextShortcut2=Libraries
TextShortcut3=Internet
TextShortcut4=Media Player
TextShortcut5=Control Panel
TextShortcut6=Trash
TextShortcut7=ShutDown
TextPath1=::{20D04FE0-3AEA-1069-A2D8-08002B30309D}
TextPath2=shell:Libraries
TextPath3=http://google.com
TextPath4=shell:MusicLibrary
TextPath5=::{21EC2020-3AEA-1069-A2DD-08002b30309d}
TextPath6=::{645FF040-5081-101B-9F08-00AA002F954E}
TextPath7=rundll32.exe user32.dll LockWorkStation
Can anyone tell me what
::{20D04FE0-3AEA-1069-A2D8-08002B30309D}
::{21EC2020-3AEA-1069-A2DD-08002b30309d}
::{645FF040-5081-101B-9F08-00AA002F954E}
these are
and also how can we get one of these for a specific location from our computer.
Those are CLSID (Windows Class Identifiers). Certain special folders within the operating system are identified by unique strings.
20D04FE0-3AEA-1069-A2D8-08002B30309D is My Computer
21EC2020-3AEA-1069-A2DD-08002b30309d is Control Panel
645FF040-5081-101B-9F08-00AA002F954E is Recycle Bin
Source:
http://www.sevenforums.com/tutorials/110919-clsid-key-list-windows-7-a.html
In response to the comment:
can i have Class Identifiers for any folder on Computer or is it just
the bunch of those.
There isn't much reason for you to add more clsids, since you can just go to other locations by typing the normal path. This is a set list that is in the registry somewhere for special folders that don't really have "paths" like C:\windows does.
what is "shell:Something" is it a cmd command or location
shell: is similar to above. It is a convenient way of accessing special folders. Here is a good site for a list: http://smallvoid.com/article/winnt-shell-keyword.html . It is more of a shortcut for Windows Explorer to access a specific location than it is a command. You cant use them in batch files as far as I know (no command line stuff).
what is %something% like %temp%
Those are environment variables. You can usually count on certain ones existing, but the user can change these. Here is a list of some more: http://en.wikipedia.org/wiki/Environment_variables#Microsoft_Windows
how do they all differ?
Well, basically, they are just different ways of accessing the same thing. Some things are more backwards compatible than others, so you have to make that choice when the time comes. If you know your app is going to be on Windows 7 and above, you can make use of some of the more convenient shell:something ones. But if it needs to run on Windows 2000, you might have to rely more on older stuff like environment variables. Environment variables can also be customized by the user.
I need to create a directory inside a windows users 'home' directory (c:\Documents and Settings\someusername\ or c:\users\someusername\). This directory will exist permanently but will only contain temporary files.
What is is the best location for this directory within the users profile if I want to be a good citizen? I should note that my program will be run by (possibly) non-admin users and will only need access to their own profile, but they must have permission to create the folder.
Using My Documents\NameOfMyApp\ is possible I guess, but that seems intrusive.
Is there a better location for this type of data, and a specific MFC call to access it?
I'd consider using the AppData directory. You can get its location with SHGetSpecialFolderLocation passing it CSIDL_APPDATA; (or a number of alternatives -- nearly every version of Windows adds a new replacement for SHGetSpecialFolderLocation, SHGetSpecialFolderPath, or (often) both).
Take a look at the following win32 calls:
GetUserProfileDirectory
GetAllUsersProfileDirectory
GetDefaultUserProfileDirectory
You probably want to use GetUserProfileDirectory and put your data in a sub-directory with your appname.
You will definitely want to use the function because there is no "\documents and settings" folder on vista and up, they changed to it "\user".
Being a good application citizen, you should use:
[drive]:\Documents and Settings[username]\Application Data[AppName] or
[drive]:\Documents and Settings[username]\Local Settings\Application Data[AppName]
(On Vista and Win7, "Documents and Settings" is replaced, most sensibly with "Users")
The environment variable USERPROFILE will provide the, you guessed it, User Profile Path.
The TEMP path provides the path to the user's individual temp directory
If the temp files aren't user-specific, you could use C:\temp
EDIT: If you are to use a user-specific location, I highly recommend that you use the environment variables (USERPATH on XP and 2000) rather than hard-coding the paths.
-Waldo
P.S. Thank you for asking this. I see bad behaviour from Waaaay too many applications. The root of the C: drive is not where you should be dumping things! At the very least, (test for the presence of, creating if necessary, and) use C:\Temp.
I have an old update program written in vb6, which runs as admin. However, because it runs as admin, all the files it downloads and saves are read-only to other users. Even files in public places like the shared application data folder (which is where I'm saving the files in question).
I'm lucky I found this before the 'vista-compatible' release. Vista hides the problem by redirecting non-admin writes and future reads to a sortof 'virtual' folder. But the next update may replace the file, and the non-admin program will still go to the virtual folder and use the old file.
As the admin user, how do I allow other users full control of files I write in vb6?
The way I do this is to make it an Installer responsibility.
Use VSI 1.1 to create an Installer MSI for your application. Create an application data folder under CommonAppDataFolder.
As a post-build step run a script to perform the following:
Set the MSI database for a per-machine installation: Property table, row with ALLUSERS set to 1.
In the Directory table, locate the entry for CommonAppDataFolder and obtain its directory Index. Use this Index to query the Directory table for an entry where CommonAppDataFolder is the parent and obtain its Index (this is your app data subfolder).
Look in the File table to obtain the component Index of your program.
Create the CreateFolder table in the database if it isn't present. Add a row to CreateFolder for the desired application subdirectory by its Index, tying it to your program's component Index.
Create the LockPermissions table if it isn't present. Insert a new LockPermissions row for your application data subdirectory, giving it FILE_ALL_ACCESS for Everyone.
That's about it.
You can do it this way, or use VSI 1.1 and then edit the MSI using Orca, or probably by using a 3rd party MSI authoring tool these entries will be settable via its GUI and can be saved in the Installer project. I just use a small WSH script I run after each VSI 1.1 build.
AFAIK this is the recommended way of accomplishing such things according to Windows application guidelines. If your needs are fancier you might use multiple subdirectories or sub-subdirectories some allowing full access, some read-only, etc.
Your program can locate the folder using Shell Automation objects or by calling Shell32 as a standard DLL (using Declare Function or a TLB).
It's not necessarily who writes the file, but where they write it to. The program files folder and it's sub folders are read-only to all standard users by default. Try using the All Users Application Data folder instead.
This is a little tricky for VB6, since it was not at all designed with Vista in mind. Some of the relevant folders were re-named and there's no way I know to get vb6 to give you the exact folder you want short of using a "Declare Function" alias to call directly into the windows API.
So the easiest reliable way I know to find a suitable location is to use the %ALLUSERSPROFILE% environment variable. That returns "C:\Documents and Settings\All Users" by default on XP and "C:\ProgramData" by default on Vista. From there you can look for an "Application Data" folder. It won't be there and you don't need it on Vista, but creating one if it doesn't exist won't hurt anything. That gives you a consistent folder structure on both systems from which you can create a sub folder for your app to use as a work space.
And one final note: this isn't a new change for Vista. Program Files folders have always been read-only to standard users by default. XP worked the same way. It's just that so many people run as administrators in XP you might be able to get away with it.
For several of our applications we use an application configuration file. It usually just stores some directory paths and a few universal settings. We usually save it in the application directory (C:/Program Files/MyAppName)
One problem we see is users want to edit this (from the application) while logged in as a user that doesn't have access to write to the directory. Our applications are commonly installed and initially configured as an admin, but mostly used by (several different) limited users.
Is there a good way to make the setting.xml file read/write accessible to all users? Or a good place to put it?
C:\Documents and Settings\All Users\Application Data\<Your App> might be a decent place to consider.
Pass CSIDL_COMMON_APPDATA to SHGetSpecialFolderPath to get the writable, shared root data directory. Given that you can create a directory for your company and application.
Application data folder or moving to registry.
How important is localization? If localization isn't a high priority, you can store the files in %allusersprofile%\Application Data\ - that's the appdata folder accessible to all user accounts, and will work regardless of where things are installed, but only on English operating system installs.
If you want to store a file in the local user's directory and give each user their own, you can use %appdata% - that one will be entirely localized. But, each user will need their own copy, so it won't work if you need a common configuration.
If you need it to both be common to all users, and be 100% localized, you need to do a bit more work. I tried to find something like %allusersappdata%, and while I can find references online to that string, I can't get it to work on my own system. The workaround I found was to pull up %appdata% to find the localized text for the words Application Data, then use that to browse to that subfolder under %allusersprofile% - a bit more complicated, but it's the most bulletproof way I can find to do it. Someone please correct me if there's a direct path you can use to get to that folder.
I would try this previous question.
Which says:
System.Environment.SpecialFolder.LocalApplicationData
If you are using .NET