Re: [boost] [filesystem] home_directory_path

Subject: Re: [boost] [filesystem] home_directory_path
From: Bjørn Roald (bjorn_at_[hidden])
Date: 2010-10-20 16:44:50

On 10/20/2010 01:33 PM, Stewart, Robert wrote:
> 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.

Wrong.  I agree with statements in other postings that the home 
directory on Unix/Linux is not anything 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.

I assume you are talking about default for something that matches "My 
Documents" on Windows.  I see absolutely no reason a boost::filesystem 
method that return the users My Documents folder on Windows should not 
return the users home directory on POSIX.  What is so wrong with that?  
What problems should arise?

As far as having a default behavior for these methods, assuming you with 
default mean something to fall back to when the primary method fails, I 
don't know if defaults are a good idea and I never suggested it.  I 
think the proper strategy is to try a defined sequence of zero or more 
established techniques to find a valid existing directory covering a 
defined boost::filesystem concept for the given platform runtime 
environment.  If that all fail it is probably best for the function to 
give up and and fail rather than guessing on some default directory and 
possibly trying to create the path.

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

I still see no problems with just using $HOME on unix like systems as a 
match to My Documents.  They do not have to be equivalent, they just 
need to be a place in the filesystem that serve the same concept for the 
software.  An example is the concept of a directory under which the 
users private documents normally are organized.

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

I never sugested this table as a mapping.  Immediately before my table I 
had text you have cut away, I quote myself:

 >> A set of  names of methods/enums and typical returned paths could be:

So please do not suggest I simply suggested a mapping.

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

Agree, hence I put my question marks.  Also, there is no standard way of 
defining the path to the desktop if there where a GUI.  I do not even 
know if all GUI's have the concept of a desktop, or if they do if all of 
them map this to a filesystem directory.

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

>    /etc is not appropriate as the user won't have write permission unless root.

That is why I suggested this to be similar to

c:\Documents and Settings\All Users\AppData

on Windows which typically require Administrator rights.

>   If such were to be supported by Filesystem, the best behavior remains leave undefined what has no standard definition.
>    

The tricky part here is to come up with the desired concepts we want 
support for in boost::filesystem and then determine if there is a good 
solution on each relevant runtime platform.  Looking for defined 
equivalence is the same as giving up.  Then we will gain nothing.

regards,

Bjørn