Re: [boost] [filesystem] home_directory_path

Subject: Re: [boost] [filesystem] home_directory_path
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2010-10-25 07:44:11

Bjørn Roald wrote:
> 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.

Good.  Apology accepted.

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

OK.  Please do try to account for all others have posted when writing or, at least, when another refers you to earlier arguments, have the courtesy to review the earlier posts to find the claimed arguments rather than expecting them to be reiterated.

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

Good so far.

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

Agreed.  That's where I foresee that there is not going to be a single policy that will satisfy all clients, meaning that hard coding one into Filesystem will be problematic from a justification and maintenance standpoint.  To wit, a Trac issue is created asking, "Why isn't XYZ platform's configuration directory properly supported?"  Then, Beman will need to learn about that platform, may well discover that its convention conflicts with that of another platform making distinguishing one from the other impossible.  If that happens, what can he do but ostracize the requester -- and others using the XYZ platform -- by virtue of not being able to remove support for the platform already supported?

> 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

OK

> 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

That's a lot of work for what's (soon-to-be) a header only library, isn't it?  Still, it isn't unreasonable to expect.

> 3.
> signal failure

OK

That's good.  Previously, you were quite vague about what you thought should be included and simply argued against my use of the word, "default."  Now I have a better understanding of your thoughts.

> >> 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 :-)

You stated previously that you'd use the zzzz directory; I pointed out the need for it being called the .zzzz directory.

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

You're suggesting that an application using Filesystem should be written with portability in mind so it will, of necessity, eschew proprietary things like the Windows registry whenever possible.  That may be reasonable, but it also makes such applications less like the norm for a given platform, right?

My point was that the directory name was different, the file formats were very likely different, some data that would be in the app data directory on POSIX systems would likely be in the Windows registry and, for all I know, somewhere else on OS X, etc., so there are a great many differences that call into question its providing real portability, and thus whether Filesystem should support such a thing.

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

OK.  There are certainly some applications for which that is appropriate.  The question is whether there are enough to make Filesystem support worthwhile.  I can't answer that question, but it should be asked.

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