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
>> user_(home|profile)_path /home/bjorn
>> c:\Documents and
>> 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
>> user_desktop_path /home/bjorn/Desktop ??
>> c:\Documents and Settings\bjorn\Desktop
>> desktop_path /etc/Desktop ??
>> c:\Documents and Settings\All Users\AppData
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk