Subject: Re: [boost] [filesystem] home_directory_path
From: Jeff Flinn (TriumphSprint2000_at_[hidden])
Date: 2010-10-20 08:51:27
Christian Holmquist wrote:
> On 19 October 2010 07:11, Jeff Flinn <TriumphSprint2000_at_[hidden]> wrote:
>> Christian Holmquist wrote:
>>> You might be better off calling SHGetFolderPath with a CSIDL value like
>>>>> I think CSIDL_APPDATA is not the correct flag, we're using the
>>> 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:
> while the environment variable "USERPROFILE" is set to C:\Documents And
> 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,
> 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_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
> 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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk