Re: [boost] [filesystem] home_directory_path

Subject: Re: [boost] [filesystem] home_directory_path
From: Christian Holmquist (c.holmquist_at_[hidden])
Date: 2010-10-19 12:56:45

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?
Without a way to retrieve My Documents, I for one still needs my own wrapper
for that..

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

> Also consensus from discussion on temp_directory_path was that the library
> should *not* create a directory if one doesn't exist.
>
>
I agree.

> Hmm, the other drawback of this function is the lack of ability to get the
> buffer size, and no documented error code corresponding to insufficient
> buffer size. Is it guaranteed that the buffer size = MAX_PATH is always
> sufficient?
>
>
> I think ther's a lot of code out there that depends on MAX_PATH always
being sufficient, but I found here:
http://msdn.microsoft.com/en-us/library/aa365247%28VS.85%29.aspx
that one could retrieve this value from GetVolumeInformation.

Is the strategy to use the SHGetFolderPathW, and then convert to utf8? It
seems the Wide version has a maximum size of roughly 32kb.

Christian