Re: [boost] [filesystem] home_directory_path

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
>>>>> 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