Re: [boost] [filesystem] home_directory_path

Subject: Re: [boost] [filesystem] home_directory_path
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2010-10-19 14:51:34

Christian Holmquist wrote:
>
> 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?

Given that My Documents is nothing more than a common directory into or under which to deposit all user-produced content, it's only special in that Microsoft thought Windows users were too silly to decide for themselves where and how to organize their files.  POSIX systems don't make that assumption, so there is no equivalent.  Having said that, it is not uncommon to have a directory dedicated as a default location for files that don't have a more specific place.  However, the choice of directory is user-specific.

> 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 was thinking of something similar: indicate which directory is wanted by a discriminator.  As for names, I'd definitely avoid "windows."  In your example, "path_windows_my_documents" could be "path_documents" and still serve just as well.

Given that there is no specific My Documents equivalent on POSIX systems and no specific home directory on Windows, perhaps the better approach is to have calls for those throw an exception unless the application first defines their location.  That is, Filesystem could offer a standard API for accessing such paths but require the actual path be specified -- once per run -- when there's no OS default.  The advantage is that most code can use the common API and only initialization code must set the ambiguous paths according to some local policy and the current platform.

Therefore:

   namespace filesystem
   {
      path
      set_os_path(os_path_t, path const &);

      path
      set_os_path_from_environment(os_path_t, std::string const &);
   }

(It returns the previous path, if any.)

What's missing is the ability to set a policy that indicates Filesystem should try some particular e-var and, if that's not set, check for a particular directory, and if that doesn't exist, throw an exception.  That would be the most useful.  Perhaps the right behavior is to simply install a function that Filesystem can call to provide the path when needed.

It may be handy to provide a feature query function, too:

   namespace filesystem
   {
      bool
      is_os_path_available(os_path_t);
   }

If get_os_path() calls a user-installed function, then is_os_path_available() would have to call the former in a try block, of course.

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer, Core Software      using std::disclaimer;
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.