Re: [boost] [filesystem] home_directory_path

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

On 10/21/2010 02:15 PM, Stewart, Robert wrote:
> Bjørn Roald wrote:
>    
>> 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.
>>>>          
>
>>> 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?
>>      
> Since there is "absolutely no reason" that the home directory isn't appropriate, and I've enumerated various reasons against that mapping in other posts, there's no point in my answering your questions.
>    

I said "I see no reason", I still do not see any.  But I may be blind ;-)

>> 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.
>>      
> Um, no.  The idea of a default is what you get when you don't do anything to change the answer.
>
>    

Right, the effect is the same.  Technically it is most often simpler to 
set the default first and let it be overwritten - yes.  Defaults too me 
means you always have a value, you never fail to provide one.  Sure some 
value types may have a convention for an invalid value, if used as 
default you could signal failure trough 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.
>>      
> I've been contending for the "zero" in "zero or more" because there's no really good mapping.
>    

if you replace "because" with "if", then I agree with the above.

>> 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.
>>      
> You contend that the fallback, in this case, is the home directory.  That's the default.
>    

Absolutely not.  There is no way you can be sure there is a valid home 
directory for the current user - so how can that be a default.  You have 
to test a few thinks, if that fails to find a valid home directory, then 
the only sensible alternative is to return that fact to the caller.

>> 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.
>>      
> What's the difference between being "equivalent" and serving "the same concept" as you've used those terms above?  I find no difference between those, so I read the above as "they don't have to be equivalent, they just have to be equivalent."
>    

for my notion of concepts here, the following apply:

posix_home_dir  is a user_doc_dir
posix_home_dir  is a user_profile_dir
posix_home_dir  is also other things that may be mapped to useful concepts

user_doc_dir is not a user_profile_dir and vice versa
hence neither of those two concepts are a posix_home_dir
it follows that there is no equalence between user_doc_dir and 
posix_home_dir, but we still have that posix_home_dir  is a user_doc_dir

The point is that the posix_home_dir serves fine as a user_doc_dir 
without being the same thing by every letter of the law.

>>> 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.
>>      
> If a given function returns X on platform A and it returns Y on platform B, then X and Y are equivalents between the two platforms A and B and therefore, one maps to the other.  I have no idea what you read into the word "mapping" but your table clearly indicates equivalencies between directories on the two platforms.
>    

They where examples of typically returned paths.  You can argue that 
they are mapping of such - fine.  But they are not mappings of suggested 
defaults.

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

>>>     /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 you say so.  I couldn't make sense of your table.  By the time it arrived, it was munged beyond readability.
>    

sorry about that - my bad.  I did not realize my editor used a 
proportional font.

>> 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.
>>      
> I have no idea what you're saying because that reads as, "find the desired concepts to support and look for a good default, but doing so is the same as giving up."
>    

Where did you get "good default" from?

I try to rephrase my intended message:

Finding a perfect solution is impossible, so we should just give up.  Or 
--- maybe, if we can find something that is very valuable and useful for 
boost::filesystem users, then we can accept a few scratches in the paint.

-- 
Bjørn