Re: [boost] [filesystem] home_directory_path

Subject: Re: [boost] [filesystem] home_directory_path
From: Bjørn Roald (bjorn_at_[hidden])
Date: 2010-10-22 17:09:22

On 10/22/2010 01:11 PM, Stewart, Robert wrote:

> Bjørn Roald wrote:
>    
> I have given reasons. You may say you find them insufficient, but even 
> with the qualifier, "I see absolutely no reason," dismisses the 
> rationale I've given out of hand.

Well, I am happy to settle with me finding the arguments insufficient 
and strike out "I see absolutely no reason" statement as it clearly is 
offending, something I did not intend - sorry.  In any case I seriously 
think I may have missed points you have made in other posts.  My 
statements was based om my understanding of the issue, and not a good 
understanding of all points made by others (including you) throughout 
this discussion.

> So far, despite your suggestion that there are a few things to test, I understand you to be saying return the home directory, provided it exists.  If it doesn't exist, then signal an error (likely via exception).  If there are other things to check before signaling an error, please be explicit about what you mean.
>    

Ok - we are discussing what a possible function returning the "My 
Documents" would return on Linux/UNIX and possibly also OSX platforms.  
Let us call this the user_doc_dir concept.  This concept cover a natural 
place for the user to organize private documents.  The directory is 
generally not shared, although most if not all systems will allow the 
users to make data public and accessible by others.  Further if there 
exist a GUI similar to Explorer in Windows, this GUI will typically have 
easy access to the user_doc_dir to lead the user into saving documents 
at that location in the filesystem.  Such GUIs exist on all modern 
desktop systems I am aware of.  All of them lead the users to save 
documents in their home ($HOME) directory by means of some prominent GUI 
text and/or icon typically with a house symbol.

In the Mac world this is Finder.  On my recent Kubuntu it is called 
Dolphin, in Ubuntu I think it is Nautilus, ...

First of all I have not attempted to dig into any details, so there is 
likely to be variations on different Linux distributions and UNIX 
systems. Also there are many solutions for desktop environments which 
users to some extent can choose freely among, so this is not easy.

1.
Let us assume that there exist some known solutions where user_doc_dir 
differ from the home directory.  If there exist information about this 
boost::filesystem should check for this first, if a valid path is found 
with read/write/execute permissions, it should be used, else

2.
Parse /etc/passwd to find home directory of user,
alternatively check pwd command output or $PWD value in a fresh shell or 
immediately after calling cd with no arguments,
alternatively check $HOME value,
if a valid path is found with read/write/execute permissions, it should 
be used, else

3.
signal failure

>>>>>      The AppData "folder" on Windows has no equivalent on
>>>>> POSIX systems.
>>>>>
>>>>>            
>>>> Why not?  For the same concept as the Windows users
>>>> AppData on POSIX systems the home directory works just fine.
>>>> I have many directories in my Linux home directory containing
>>>> application data for their respective applications. Many of
>>>> these applications put their data in hidden files/directories
>>>> to avoid polluting the home directory too much, but it is the
>>>> standard solution as far as I can tell.
>>>>
>>>>          
>>> AppData is a rather structured, common location, away from
>>> other directories, that well-behaved applications are
>>> supposed to use.  On POSIX systems, there is no common
>>> storage approach for data of that sort.  Given that the
>>> manner in which such data is stored differs on the two
>>> platforms, there's no reason to suppose that the two
>>> directories will offer anything useful between the two
>>> platforms.  Since everything about that data is platform
>>> specific, there is no point in Filesystem providing an
>>> accessor for such directories.
>>>        
>> Hold on...  I write application zzzz.  I want to store
>> application data for that application in a subdirectory called
>> zzzz in a sensible place unique for each user on whatever
>> platform my code runs on.  I ask
>> boost::filesystem::user_appdata_dir for that.  If it return a
>> usable path, then I create the zzzz subdirectory if it is not
>> there already and store the data.  Later I can read or write
>> data in the same place with help of boost.  I do not need to
>> worry about how this could be different on a different
>> platform.  That is the whole point.
>>      
> The convention on *nix systems is usually to create a .zzzz directory in the user's home directory, not a zzzz directory.

Right, so it make sense to do a simple test if we are on a POSIX system 
and make that dot caount :-)

>    Furthermore, a Windows application will store a good deal of information in the registry which has no equivalent elsewhere.  Consequently, the format, location, and layout of the configuration data will differ between the platforms.

Right, I think the registry is more associated with 
boost::program_options than boost::filesystem.  Nevertheless I think 
complete and portable support of program_options concepts in boost is 
lacking, especially as far as Windows Registery as a database.  It is 
not clear to me what advantages the repository provides over file based 
configurations except for ordered locations for data, simple consistent 
API, and possibly some expectations to well behaved applications.

I think there may be standards for data in the Windows registry 
supporting package management, windows installers, uninstallers and so 
forth.  All modern OS/distros have similar databases for package 
management, so I think use of the registry for storing such package 
management data is orthogonal to use of registry to store application data.

> Why then, would Filesystem try to offer something so much different as a general concept across platforms?
>    

I have made many windows programs work without entries in registry that 
I am aware of.  So I think it is mostly up to the application author how 
much if any registry is required.  I for one would find a 
user_appdata_dir function useful.

> I have no experience with Macs, so I don't know how such data is managed on that platform, but I suspect it will be different in non-trivial ways from Windows and *nix.
>    

I think Jeff answered this in his reply to you.

-- 
Bjørn