Re: [boost] [filesystem] home_directory_path

Subject: Re: [boost] [filesystem] home_directory_path
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2010-10-21 08:15:01

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

Well, thanks.  Apparently, I'm just wrong and there's no need to discuss the matter further.

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

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

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

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

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

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.

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

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

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

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