
Christian Holmquist wrote:
On 19 October 2010 07:11, Jeff Flinn <TriumphSprint2000@hotmail.com> wrote:
Christian Holmquist wrote:
You might be better off calling SHGetFolderPath with a CSIDL value like
CSIDL_APPDATA. http://msdn.microsoft.com/en-us/library/bb762181.aspx http://msdn.microsoft.com/en-us/library/bb762494.aspx
I think CSIDL_APPDATA is not the correct flag, we're using the following args to SHGetFolderPath, and it appears to work
char path[MAX_PATH]; bool success = SUCCEEDED(SHGetFolderPath(NULL, CSIDL_PERSONAL | CSIDL_FLAG_CREATE, NULL, 0, path))));
CSIDL_PERSONAL corresponds to the user's 'My Documents' folder, whereas CSIDL_PROFILE corresponds to the user's profile directory which is more consistent with the POSIX 'HOME' directory.
Ok, I've always thought of My Documents as the HOME directory on Windows. At my current location, My Documents points to: \\file01\private\chrhol\ while the environment variable "USERPROFILE" is set to C:\Documents And Settings\chrhol. The fact that some stuff is saved to local C:\ drive is to me annoying, I never fully understood this..
Is there a POSIX equivalent for My Documents?
No, but Mac OSX is similar to Windows - or is it the other way round?;-) - where HOME is defined as /Users/name which contains Documents, Desktop, etc.
Without a way to retrieve My Documents, I for one still needs my own wrapper for that..
Yes, that's what hit me when I looked at how home was used in our client code. Not just the issue of portable access but also localization.
About the boost.filesystem API, maybe it'd be a good idea to have it similar to the SHGetFolder function, i.e. the user passes an enum about which special path (s)he wants, instead of a separate call for each.
enum os_path_t { path_temp, path_home, path_windows_my_documents, // Or is this too ugly? };
namespace filesystem { path get_os_path(os_path_t) }
os_path might not the best name, but you get the idea..
I would prefer simply named functions that give me what I ask for. temp_directory_path() - we already have this on trunk home_directory_path() documents_directory_path() desktop_directory_path() ...
Is the strategy to use the SHGetFolderPathW, and then convert to utf8? It seems the Wide version has a maximum size of roughly 32kb.
Yes, filesystem uses the xxxW api's. Hmm, so boost::filesystem::path::value_type buf[~32KB]? Would there be complaints putting this on the stack? Jeff