Quantcast

[filesystem] home_directory_path

classic Classic list List threaded Threaded
61 messages Options
1234
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[filesystem] home_directory_path

Jeff Flinn
In looking at implementing a portable home_directory_path function a few
questions arise.

Based on http://en.wikipedia.org/wiki/Home_directory, POSIX and other
UNIX flavors 'appear' to be a straight forward use of the "HOME"
environment variable. Does anyone have any experience where the "HOME"
variable is not the proper source of the user's home directory?

Windows NT and above have the "USERPROFILE" environment variable. Using
this would be the easiest to use. But I've seen discussion that this may
not always be properly defined, in particular if the user has reset
their home directory to a non-system drive. I haven't tracked down it's
availability on WinCE. Does anyone have experience with this platform?

There is the windows GetUserProfileDirectory api function also available
since NT4. This is in the Userenv.lib/dll, obviously adding a link
dependancy. How are these sorts of system link dependencies handled?
Through bjam? Or is it acceptable/better to use #pragma
comment(lib,"Userenv.lib")?

In looking at some client code using home_directory_path, I see that
they generally are looking for the user's Desktop directory(Mac &
Windows). Obviously this only makes sense on GUI platforms. The issue
with merely getting this path via home_directory_path() / "Desktop" is
IIRC, that at least on windows "Desktop" is localized and may not exist
with that name on non-english localized systems. Windows has the
SHGetFolderPath api. I need to look into Mac's native support. Any
thoughts on the general usefulness of a portable desktop_directory_path?

Thanks, Jeff

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [filesystem] home_directory_path

Marsh Ray-3
On 10/18/2010 09:58 AM, Jeff Flinn wrote:

> In looking at implementing a portable home_directory_path function a few
> questions arise.
>
> Based on http://en.wikipedia.org/wiki/Home_directory, POSIX and other
> UNIX flavors 'appear' to be a straight forward use of the "HOME"
> environment variable. Does anyone have any experience where the "HOME"
> variable is not the proper source of the user's home directory?
>
> Windows NT and above have the "USERPROFILE" environment variable. Using
> this would be the easiest to use. But I've seen discussion that this may
> not always be properly defined, in particular if the user has reset
> their home directory to a non-system drive.

I wouldn't count on it for anything critical.

> I haven't tracked down it's
> availability on WinCE. Does anyone have experience with this platform?
>
> There is the windows GetUserProfileDirectory api function also available
> since NT4.

That's a the call to use if indeed you want "the root directory of the
specified user's profile".
http://msdn.microsoft.com/en-us/library/bb762280.aspx

_But it's important to be prepared for case where the code is executing
as a user who does not actually have a profile on the machine!_

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

> This is in the Userenv.lib/dll, obviously adding a link
> dependancy. How are these sorts of system link dependencies handled?
> Through bjam? Or is it acceptable/better to use #pragma
> comment(lib,"Userenv.lib")?
>
> In looking at some client code using home_directory_path, I see that
> they generally are looking for the user's Desktop directory(Mac &
> Windows). Obviously this only makes sense on GUI platforms. The issue
> with merely getting this path via home_directory_path() / "Desktop" is
> IIRC, that at least on windows "Desktop" is localized and may not exist
> with that name on non-english localized systems. Windows has the
> SHGetFolderPath api. I need to look into Mac's native support. Any
> thoughts on the general usefulness of a portable desktop_directory_path?

It seems to me like if you're going to work with a "Desktop", you're
going to need a variety of platform specific logic to deal with things
like file types, icons, app associations, etc. You'd need a real
platform UI layer. So I don't think a single function to just find the
path is likely to be useful to many.

- Marsh
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [filesystem] home_directory_path

Jeff Flinn
Marsh Ray wrote:

> On 10/18/2010 09:58 AM, Jeff Flinn wrote:
>> In looking at implementing a portable home_directory_path function a few
>> questions arise.
>>
>> Based on http://en.wikipedia.org/wiki/Home_directory, POSIX and other
>> UNIX flavors 'appear' to be a straight forward use of the "HOME"
>> environment variable. Does anyone have any experience where the "HOME"
>> variable is not the proper source of the user's home directory?
>>
>> Windows NT and above have the "USERPROFILE" environment variable. Using
>> this would be the easiest to use. But I've seen discussion that this may
>> not always be properly defined, in particular if the user has reset
>> their home directory to a non-system drive.
>
> I wouldn't count on it for anything critical.

Can you expand on that? What problems have you encountered.

>> I haven't tracked down it's
>> availability on WinCE. Does anyone have experience with this platform?
>>
>> There is the windows GetUserProfileDirectory api function also available
>> since NT4.
>
> That's a the call to use if indeed you want "the root directory of the
> specified user's profile".
> http://msdn.microsoft.com/en-us/library/bb762280.aspx
>
> _But it's important to be prepared for case where the code is executing
> as a user who does not actually have a profile on the machine!_

Of course. home_directory_path will have the same error capabilities as
the recently added temp_directory_path function

> 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
>
>> This is in the Userenv.lib/dll, obviously adding a link
>> dependancy. How are these sorts of system link dependencies handled?
>> Through bjam? Or is it acceptable/better to use #pragma
>> comment(lib,"Userenv.lib")?

Ah, SHGetFolderPath uses shell32.dll, but doesn't require and import
library. I'll take a look at using this with CSIDL_PROFILE which
corresponds to the GetUserProfileDirectory function.

>> In looking at some client code using home_directory_path, I see that
>> they generally are looking for the user's Desktop directory(Mac &
>> Windows). Obviously this only makes sense on GUI platforms. The issue
>> with merely getting this path via home_directory_path() / "Desktop" is
>> IIRC, that at least on windows "Desktop" is localized and may not exist
>> with that name on non-english localized systems. Windows has the
>> SHGetFolderPath api. I need to look into Mac's native support. Any
>> thoughts on the general usefulness of a portable desktop_directory_path?
>
> It seems to me like if you're going to work with a "Desktop", you're
> going to need a variety of platform specific logic to deal with things
> like file types, icons, app associations, etc. You'd need a real
> platform UI layer. So I don't think a single function to just find the
> path is likely to be useful to many.

Well, in our case it's a well known location where users have installed
other (legacy)apps that we need to communicate with. Nothing to do with
icons, file types,...

Thanks, Jeff

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [filesystem] home_directory_path

Christian Holmquist
>
>  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))));

..and I think this would be a most useful addition to boost::filesystem.


HTH,
Christian
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [filesystem] home_directory_path

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

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

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?

> ..and I think this would be a most useful addition to boost::filesystem.

Me too. I've needed this in projects for several different employers
over the years.

Jeff

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [filesystem] home_directory_path

Christian Holmquist
On 19 October 2010 07:11, Jeff Flinn <[hidden email]> 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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [filesystem] home_directory_path

Stewart, Robert
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                           [hidden email]
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.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [filesystem] home_directory_path

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

Sure, but the documentation must state clearly on which platforms it can be
expected to have a default implementation.


>
> 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 &);
>   }
>
>
>
This I like, but do you need set_os_path_from_environment?
set_os_path(X, boost::getenv("Y")) would suffice IMO, surely boost must
somewhere have a
string getenv(string) (?)



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

with set_os_path I think users can do that themselves. Installing a callback
function seems a little over-engineered, what would be the benefits?


>
> 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.
>
>
I thought you were aiming at having filesystem configured at initialization
with set_os_path.
get_os_path() should IMO throw if there's no platform specific
implementation for the discriminator and the user has not explicitly set the
path.

Do you have a particular implementation of such a user-defined function that
would benefit from lazy evaluation? I have a feeling I'm missing your point.

Christian
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [filesystem] home_directory_path

Bjørn Roald
In reply to this post by Christian Holmquist
On 10/19/2010 06:56 PM, Christian Holmquist wrote:
>
> Is there a POSIX equivalent for My Documents?
>    

I think the users home directory is the closest you get as a general
statement unless you start getting into details that are more specific
for each POSIX system and/or distribution.

> 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?
> };
>    

It is not ugly - maybe a bit wordy and not so portable.  Why not having
the function returning the "My Documents" folder on Windows return the
home directory on POSIX.  That way that method can be used if you desire
My Documents on Windows but still work in a sensible way on POSIX
systems. A set of  names of methods/enums and typical returned paths
could be:


method name                                POSIX  path        XP path
-------------------------------------------------------------------------------------------------
temp_path                                     /tmp                    
c:\TEMP
user_(home|profile)_path             /home/bjorn        c:\Documents and
Settings\bjorn
user_docs_path                             /home/bjorn        
c:\Documents and Settings\bjorn\My Documents

this could possibly be extended to other useful operating environment
paths if it make any sense and it is possible to find useful mapping on
all systems:

user_appdata_path                      /home/bjorn                      
c:\Documents and Settings\bjorn\AppData
appdata_path                               /etc      
                               c:\Documents and Settings\All Users\AppData
user_desktop_path                      /home/bjorn/Desktop  ??  
c:\Documents and Settings\bjorn\Desktop
desktop_path                               /etc/Desktop ??      
            c:\Documents and Settings\All Users\AppData
etc..

Before any of these are to be supported they should be deemed useful and
robust ways of getting correct results on all target systems must be
found for each function.

> namespace filesystem
> {
>   path get_os_path(os_path_t)
> }
>
> os_path might not the best name, but you get the idea..
>    

I have no preference for either enum based or multiple function based
solution, but I am curious to what the benifit of an enum based solution
is.

--
Bjørn
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [filesystem] home_directory_path

Chad Nelson-2
In reply to this post by Stewart, Robert

I've been following this discussion with great interest, since I often
have need of a portable way to get these paths. If I may contribute my
two cents' worth:

On Tue, 19 Oct 2010 14:51:34 -0400
"Stewart, Robert" <[hidden email]> wrote:

> Christian Holmquist wrote:
>>
>> Ok, I've always thought of My Documents as the HOME directory
>> on Windows. [...] 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. [...]

Having seen how many (non-technical) people just dump all their files on
their computer's desktop, I'm afraid I have to side with Microsoft on
that one. :-)

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

You said yourself, above, that My Documents on Windows is intended to be
the repository of user-generated content. (As opposed to the
"USERPROFILE" directory, which is presumably for program-generated
files such as configuration files.) On *NIX systems, the user's home
directory, or more often a user-selected subdirectory of it, serves
the same purpose. So as Bjørn Roald said in another reply, why not just
return the user's home directory for the document path?
--
Chad Nelson
Oak Circle Software, Inc.
*
*
*

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [filesystem] home_directory_path

Christian Holmquist
In reply to this post by Bjørn Roald
>
>>
>
> I have no preference for either enum based or multiple function based
> solution, but I am curious to what the benifit of an enum based solution is.
>
> --
>

I prefer to use enumerations when the interface allows, cause one can add
string operators to them for debugging purposes and keep them around more
easily in user-defined structs. Exceptions thrown from get_os_path() might
include the discriminator, making things a little easier at the catch site..


namespace example
{
struct user_file_path
{
  filesystem::os_path_t root;
  filesystem::path file_path;

  filesystem::path get() { return filesystem::get_os_path(root) / file_path;
}
};

void foo()
{
  user_file_path p = {..., ....};
  try
  {
    p.get():
  }
  catch(const bad_os_path& p)
  {
   clog << "failed to get os path " << p.os_path();
  }
}

}


Christian
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [filesystem] home_directory_path

Christian Holmquist
In reply to this post by Jeff Flinn
>
> 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.
>
>
Checking my USERPROFILE folder it does contain log files, some
.internal_folders_for_nix_like_applications and stuff that, well, belongs to
my profile (Desktop, Favorites etc)
I can't say that it resembles -more- a HOME path than does My Documents.
USERPROFILE is still a mystery to me, I would not have my applications store
anything there. :)

Christian
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [filesystem] home_directory_path

Ravi-41
In reply to this post by Christian Holmquist
On Tuesday 19 October 2010 09:56:45 Christian Holmquist wrote:
> 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..

On newer Linux systems, try $XDG_DOCUMENTS_DIR for an equivalent. Not sure
whether it will make it into POSIX.

Ravi

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [filesystem] home_directory_path

Stewart, Robert
In reply to this post by Christian Holmquist
Christian Holmquist wrote:

>
> >   namespace filesystem
> >   {
> >      path
> >      set_os_path(os_path_t, path const &);
> >
> >      path
> >      set_os_path_from_environment(os_path_t, std::string const &);
> >   }
> >
> This I like, but do you need set_os_path_from_environment?

Maybe.  I was thinking that set_os_path() might retain the path and upon query, via get_os_path(), validate the directory.  Thus, the directory need not exist when set_os_path() is called; just when get_os_path() is called.  (Filesystem could cache whether the path was validated to avoid doing so on each query.)

Likewise, I was thinking that set_os_path_from_environment() might save the e-var and leave to get_os_path() the job of accessing the e-var and, if it exists, validating the pathname given by it.

Thus, the program could modify the environment or create the "OS directory" in question after having called set_os_path*().  Is such laziness really needed?  No.  Would it be helpful or convenient?  Perhaps.  It was just a passing thought when I added set_os_path_from_environment().  However, to accommodate such behavior, the names really shouldn't begin with "set_os_path" as they wouldn't set the path so much as the policy for finding it.

> set_os_path(X, boost::getenv("Y")) would suffice IMO, surely
> boost must somewhere have a string getenv(string) (?)

If that's all that set_os_path_from_environment() entails, I quite agree with you.  If it were to do more, as suggested above, then no.

> > 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.
>
> with set_os_path I think users can do that themselves.

Sure.  The reason to put such a thing in the library is just to remove the burden from the clients that would avail themselves of that behavior.  Are there enough to justify it?  I don't know.

> Installing a callback function seems a little over-engineered,
> what would be the benefits?

That would allow initialization code to establish the policy in one place while querying code elsewhere benefits.  Filesystem can just store a path against each possible query and leave all else to the client via an eager set_os_path().  That would, of course, require that the initialization code first create missing directories, etc., and then call set_os_path().  Delaying the work, via a callback, means that the reaction to missing directories or e-vars can be handled or reported using an otherwise fully initialized application, so the handling can, for example, make use of GUI facilities that might not be available during initialization.  Again, I don't know whether that will prove useful to anyone, but that was the thought that passed through my head when I suggested the idea.

> > 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.
> >
> >
> I thought you were aiming at having filesystem configured at
> initialization with set_os_path.

There are other views of what initialization may do.

> get_os_path() should IMO throw if there's no platform specific
> implementation for the discriminator and the user has not
> explicitly set the path.

Right, but the means of setting the path could be lazy or eager.

_____
Rob Stewart                           [hidden email]
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.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [filesystem] home_directory_path

Stewart, Robert
In reply to this post by Bjørn Roald
Bjørn Roald wrote:
> On 10/19/2010 06:56 PM, Christian Holmquist wrote:
> >
> > Is there a POSIX equivalent for My Documents?
>
> I think the users home directory is the closest you get as a general
> statement unless you start getting into details that are more
> specific for each POSIX system and/or distribution.

I disagree.  The home directory is more like C:\ on Windows.  As I mentioned in another post, there is no specific equivalent.  Each user chooses to put documents in various subdirectories as suits their preference, so there isn't a good default on POSIX systems.  Some desktop environments provide an equivalent, but as there is no standard even among those, it is still up to client code to determine the best equivalent, if wanted.

> method name                                POSIX  path        XP path
> --------------------------------------------------------------
> -----------------------------------
> temp_path                                     /tmp
> c:\TEMP
> user_(home|profile)_path             /home/bjorn
> c:\Documents and
> Settings\bjorn
> user_docs_path                             /home/bjorn
> c:\Documents and Settings\bjorn\My Documents

I disagree with your mappings.  I think leaving undefined what has no standard definition is superior.  Also, temp_path should be taken from the environment before using a fallback like /tmp.

> user_appdata_path                      /home/bjorn
>
> c:\Documents and Settings\bjorn\AppData
> appdata_path                               /etc
>                                c:\Documents and Settings\All
> Users\AppData
> user_desktop_path                      /home/bjorn/Desktop  ??
> c:\Documents and Settings\bjorn\Desktop
> desktop_path                               /etc/Desktop ??
>             c:\Documents and Settings\All Users\AppData
> etc..

This gets one into even more proprietary directions.  A Desktop "folder" assumes a GUI which isn't necessarily the case on a POSIX system.  The AppData "folder" on Windows has no equivalent on POSIX systems.  /etc is not appropriate as the user won't have write permission unless root.  If such were to be supported by Filesystem, the best behavior remains leave undefined what has no standard definition.

_____
Rob Stewart                           [hidden email]
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.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [filesystem] home_directory_path

Stewart, Robert
In reply to this post by Chad Nelson-2
Chad Nelson wrote:

> "Stewart, Robert" <[hidden email]> wrote:
> > Christian Holmquist wrote:
> >>
> > 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. [...]
>
> Having seen how many (non-technical) people just dump all their
> files on their computer's desktop, I'm afraid I have to side
> with Microsoft on that one. :-)

I know, there are a great many such people.  Yes, I think Microsoft was right to do that for their general population, but Filesystem cannot choose similarly for all clients.

> > 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. [...]
>
> You said yourself, above, that My Documents on Windows is
> intended to be the repository of user-generated content. (As
> opposed to the "USERPROFILE" directory, which is presumably for
> program-generated files such as configuration files.) On *NIX
> systems, the user's home directory, or more often a
> user-selected subdirectory of it, serves the same purpose. So
> as Bjørn Roald said in another reply, why not just return the
> user's home directory for the document path?

Anything close to an equivalent on POSIX systems is likely to be a user-selected subdirectory of the user's home directory, so choosing the home directory is wrong.  Indeed, the home directory should have little but subdirectories and "dot files," just as a Windows system's C:\ should have little more than subdirectories, choosing the home directory as the default location to dump documents is wrongheaded.

_____
Rob Stewart                           [hidden email]
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.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [filesystem] home_directory_path

Alexander Churanov
In reply to this post by Jeff Flinn
Jeff and others,

As a user of both Windows and UNIX (FreeBSD), I think that the
discussion is overcomplicated. There several things an application
needs to know about the directories:

1) Where to put/find user-specific configuration-data.
2) Where to find system-wide configuration-data.
3) Where to put user-specific caches.
4) Where to find user-generated content.

For UNIX these locations correspond to:

1) .dot files (directories) under ${HOME}
2) /etc, /usr/local/etc
3) .dot files (directories) under ${HOME}
4) ${HOME}

For Windows they are:

1) Application Data\Company Name\Product Name in user profile (CSIDL_APPDATA)
2) Application Data\Company Name\Product Name in "all users" profile
(CSIDL_COMMON_APPDATA)
3) Application Data\Company Name\Product Name in user profile (CSIDL_APPDATA)
4) "My Documents" or "Desktop" folder (CSIDL_PERSONAL)

Essentially, the exact locations on Windows should be obtained via
Shell API. If this approach is used, it is only necessary to support
old and specific versions of Windows.

Note, UNIX users typically store their files under ${HOME}, it is OK
to consider ${HOME} as an equivalent of "My Documents", though they
are not the same.

Alexander Churanov
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [filesystem] home_directory_path

Stewart, Robert
Alexander Churanov wrote:
>
> As a user of both Windows and UNIX (FreeBSD), I think that the
> discussion is overcomplicated. There several things an application
> needs to know about the directories:
>
> 1) Where to put/find user-specific configuration-data.
> 2) Where to find system-wide configuration-data.
> 3) Where to put user-specific caches.
> 4) Where to find user-generated content.

I fail to see how you have simplified the discussion with that enumeration.  It may be more succinct or described in less proprietary terms, but it isn't a simplification.

> Note, UNIX users typically store their files under ${HOME}, it is OK
                                               *****
> to consider ${HOME} as an equivalent of "My Documents", though they
> are not the same.

They are definitely not the same.  As I stated elsewhere, the user's home directory is equivalent to C:\ on a Windows system.  The user shouldn't put "user-generated content" there.  It should be in some subdirectory as preferred by the user, which you understood when you wrote "under" in the quoted sentence.

_____
Rob Stewart                           [hidden email]
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.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [filesystem] home_directory_path

Alexander Churanov
2010/10/20 Stewart, Robert <[hidden email]>:
> They are definitely not the same.  As I stated elsewhere, the user's home directory is equivalent to C:\ on a Windows system.  The user shouldn't put "user-generated content" there.  It should be in some subdirectory as preferred by the user, which you understood when you wrote "under" in the quoted sentence.

I completely disagree on "C:\". The ${HOME} is user-specific, while
"C:\" is not.

It is not uncommon to put documents (including textual) in different
subdirectories under ${HOME}. For example, on my machine "lf ~" lists
"examples" and "tasks" as different directories. To my mind, none of
them entirely corresponds to "My Documents", but the whole ${HOME}
does.

Another argument: some desktop environments place an icon on the
desktop, which opens ${HOME}. Along with "System" and "Trash" this
looks very related to default Windows icons.

Alexander Churanov
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [filesystem] home_directory_path

Stewart, Robert
Alexander Churanov wrote:

> 2010/10/20 Stewart, Robert <[hidden email]>:
> > They are definitely not the same.  As I stated elsewhere,
> > the user's home directory is equivalent to C:\ on a Windows
> > system.  The user shouldn't put "user-generated content"
> > there.  It should be in some subdirectory as preferred by the
> > user, which you understood when you wrote "under" in the
> > quoted sentence.
>
> I completely disagree on "C:\". The ${HOME} is user-specific, while
> "C:\" is not.

The latter is nearly true as Windows is only barely multi-user.

> It is not uncommon to put documents (including textual) in different
> subdirectories under ${HOME}. For example, on my machine "lf ~" lists
> "examples" and "tasks" as different directories. To my mind, none of
> them entirely corresponds to "My Documents", but the whole ${HOME}
> does.

My Documents, being at once user specific and not the root directory of a drive maps well to a subdirectory of the user's home directory, not to the home directory itself.  Again, it is poor practice to overpopulate one's home directory, just as over-populating C:\ is poor practice; Filesystem should not establish that as a default.  The policy should be determined by the client, not by Filesystem as there is no agreement.

> Another argument: some desktop environments place an icon on the
> desktop, which opens ${HOME}. Along with "System" and "Trash" this
> looks very related to default Windows icons.

That there's a button to access one's home directory in no way implies that the home directory must be the default location of user-generated content.  Instead, it means the GUI doesn't know what the user might want to view, but that the home directory is the likely starting point for finding it.

_____
Rob Stewart                           [hidden email]
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.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
1234
Loading...