[filesystem] home_directory_path

classic Classic list List threaded Threaded
61 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Re: [filesystem] home_directory_path

Sebastian Redl
On 20.10.2010 14:09, Alexander Churanov wrote:

> Jeff and others,
>
> As a user of both Windows and UNIX (FreeBSD), I think that the
> discussion is overcomplicated. There several things an application
> needs to know about the directories:
>
> 1) Where to put/find user-specific configuration-data.
> 3) Where to put user-specific caches.
>
> For Windows they are:
>
> 1) Application Data\Company Name\Product Name in user profile (CSIDL_APPDATA)
> 3) Application Data\Company Name\Product Name in user profile (CSIDL_APPDATA)
3) should be CSIDL_LOCAL_APPDATA, if available, since CSIDL_APPDATA is
synced to the server for roaming profiles, which is a bad idea for caches.

Sebastian
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [filesystem] home_directory_path

Jeff Flinn
In reply to this post by Christian Holmquist
Christian Holmquist wrote:

> On 19 October 2010 07:11, Jeff Flinn <[hidden email]> wrote:
>
>> Christian Holmquist wrote:
>>
>>>  You might be better off calling SHGetFolderPath with a CSIDL value like
>>>>> CSIDL_APPDATA.
>>>>> http://msdn.microsoft.com/en-us/library/bb762181.aspx
>>>>> http://msdn.microsoft.com/en-us/library/bb762494.aspx
>>>>>
>>>>>
>>>>>  I think CSIDL_APPDATA is not the correct flag, we're using the
>>> following
>>> args to SHGetFolderPath, and it appears to work
>>>
>>>   char path[MAX_PATH];
>>>   bool success = SUCCEEDED(SHGetFolderPath(NULL, CSIDL_PERSONAL |
>>> CSIDL_FLAG_CREATE, NULL, 0, path))));
>>>
>> CSIDL_PERSONAL corresponds to the user's 'My Documents' folder, whereas
>> CSIDL_PROFILE corresponds to the user's profile directory which is more
>> consistent with the POSIX 'HOME' directory.
>>
>>
> Ok, I've always thought of My Documents as the HOME directory on Windows. At
> my current location, My Documents points to:
> \\file01\private\chrhol\
> while the environment variable "USERPROFILE" is set to C:\Documents And
> Settings\chrhol.
> The fact that some stuff is saved to local C:\ drive is to me annoying, I
> never fully understood this..
>
> Is there a POSIX equivalent for My Documents?

No, but Mac OSX is similar to Windows - or is it the other way round?;-)
  - where HOME is defined as /Users/name which contains Documents,
Desktop, etc.

> Without a way to retrieve My Documents, I for one still needs my own wrapper
> for that..

Yes, that's what hit me when I looked at how home was used in our client
code. Not just the issue of portable access but also localization.

> About the boost.filesystem API, maybe it'd be a good idea to have it similar
> to the SHGetFolder function, i.e. the user passes an enum about which
> special path (s)he wants, instead of a separate call for each.
>
> enum os_path_t
> {
>   path_temp,
>   path_home,
>   path_windows_my_documents,  // Or is this too ugly?
> };
>
> namespace filesystem
> {
>  path get_os_path(os_path_t)
> }
>
> os_path might not the best name, but you get the idea..

I would prefer simply named functions that give me what I ask for.

      temp_directory_path() - we already have this on trunk
      home_directory_path()
documents_directory_path()
   desktop_directory_path()
...

> Is the strategy to use the SHGetFolderPathW, and then convert to utf8? It
> seems the Wide version has a maximum size of roughly 32kb.

Yes, filesystem uses the xxxW api's. Hmm, so
boost::filesystem::path::value_type buf[~32KB]? Would there be
complaints putting this on the stack?

Jeff

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [filesystem] home_directory_path

John B. Turpish
In reply to this post by Stewart, Robert
On Wed, Oct 20, 2010 at 7:33 AM, Stewart, Robert <[hidden email]> wrote:

> Bjørn Roald wrote:
>> On 10/19/2010 06:56 PM, Christian Holmquist wrote:
>> 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.
+1
The fact that I see it differently but understand some of the
arguments being made here suggests to me that it should be left up to
the application developers and not guess at it in Boost.
For what it's worth I would see a correspondence something like:
$TMPDIR - %TEMP%
$HOME - %HOMEDRIVE%%HOMEPATH%
$HOME/Documents - %HOMEDRIVE%%HOMEPATH%\My Documents
And even so I'm very aware that even I don't even have a
$HOME/Documents on some of the machines I use.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [filesystem] home_directory_path

Alexander Churanov
In reply to this post by Stewart, Robert
2010/10/20 Stewart, Robert <[hidden email]>:
> The latter is nearly true as Windows is only barely multi-user.

Robert, this is surprising. What versions of Windows are to your
opinion not multi-user? I think it is worth to examine XP/Vista/7
instead of 98/Me, which are dead.

> it is poor practice to overpopulate one's home directory

I read this for the first time. Could you, please, provide some links?
The organization of user-generated files in home directory is up to the user.

Alexander Churanov
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [filesystem] home_directory_path

Stewart, Robert
Alexander Churanov wrote:
> 2010/10/20 Stewart, Robert <[hidden email]>:
> > The latter is nearly true as Windows is only barely multi-user.
>
> Robert, this is surprising. What versions of Windows are to your
> opinion not multi-user? I think it is worth to examine XP/Vista/7
> instead of 98/Me, which are dead.

Common knowledge.  Windows is a single user system with multi-user functionality overlaid.  All users have full access to C:\.

> > it is poor practice to overpopulate one's home directory
>
> I read this for the first time. Could you, please, provide some links?
> The organization of user-generated files in home directory is
> up to the user.

I have no links.  I'm sure I could find some if I tried, but this is wisdom passed down from others years past and from my own decades of experience.  No directory should be overpopulated, as a rule, because directory searches take increasingly long as the number of files grow (though some filesystems are less hampered than others) and because directory listings become unwieldy to grok visually.  The home directory is more important to not over-populate because it is already the location of dot files and all subdirectories leading to other content.  Adding user-generated content to the necessary content makes it harder to use as the jump point to all user content, whether user-generated or locally installed applications/libraries.

I hope these points help to convince you that Filesystem should not return $HOME by default.  It is better to leave that decision to the client code and a convenience default will encourage use of that default, so it ought not to be a default that leads to poor practice.

_____
Rob Stewart                           [hidden email]
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.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [filesystem] home_directory_path

Chad Nelson-2
In reply to this post by Stewart, Robert
On Wed, 20 Oct 2010 07:40:34 -0400
"Stewart, Robert" <[hidden email]> wrote:

> "Stewart, Robert" <[hidden email]> wrote:
>
>> You said yourself, above, that My Documents on Windows is
>> intended to be the repository of user-generated content. (As
>> opposed to the "USERPROFILE" directory, which is presumably for
>> program-generated files such as configuration files.) On *NIX
>> systems, the user's home directory, or more often a
>> user-selected subdirectory of it, serves the same purpose. So
>> as Bjørn Roald said in another reply, why not just return the
>> user's home directory for the document path?
>
> Anything close to an equivalent on POSIX systems is likely to be a
> user-selected subdirectory of the user's home directory, so choosing
> the home directory is wrong. Indeed, the home directory should have
> little but subdirectories and "dot files," just as a Windows system's
> C:\ should have little more than subdirectories, choosing the home
> directory as the default location to dump documents is wrongheaded.
Automatically saving user-generated content into it is wrong. Returning
it from that function might not be, if there's no better logical
candidate. Since the requested directory *is* explicitly for
user-generated content, presumably most programs would use the returned
path to pop up a load/save dialog to the user (who would then manually
navigate to his preferred subdirectory for his documents), or would
append their own subdirectory names to it before silently saving files.

That's how popular Linux programs like Firefox, Thunderbird, and Claws
Mail work, the first time they need a place to load or save files to.
And how the OS-provided programs on Ubuntu work too. (After that, most
of them use the last directory that you saved or loaded anything
to/from, and wouldn't need that function.)

So long as the behavior is documented, I don't think it would be a
problem. As a developer it's what I'd want, because if I had to write
OS-specific changes to my program to make it work, it would be a lot
less useful to me.
--
Chad Nelson
Oak Circle Software, Inc.
*
*
*

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [filesystem] home_directory_path

Lars Viklund
In reply to this post by Sebastian Redl
On Wed, Oct 20, 2010 at 02:44:25PM +0200, Sebastian Redl wrote:

> On 20.10.2010 14:09, Alexander Churanov wrote:
>> Jeff and others,
>>
>> As a user of both Windows and UNIX (FreeBSD), I think that the
>> discussion is overcomplicated. There several things an application
>> needs to know about the directories:
>>
>> 1) Where to put/find user-specific configuration-data.
>> 3) Where to put user-specific caches.
>>
>> For Windows they are:
>>
>> 1) Application Data\Company Name\Product Name in user profile (CSIDL_APPDATA)
>> 3) Application Data\Company Name\Product Name in user profile (CSIDL_APPDATA)
> 3) should be CSIDL_LOCAL_APPDATA, if available, since CSIDL_APPDATA is  
> synced to the server for roaming profiles, which is a bad idea for
> caches.

Excuse me if it's posted before in this massive thread, but Raymond Chen
says it best:
http://blogs.msdn.com/b/oldnewthing/archive/2005/07/01/434647.aspx
<< What's the difference between My Documents and Application Data? >>

As for the whole "C:\ is the user's home directory", that's just
wrong.

First of all, a regular user do not have write access anywhere on C:,
as there's ACLs to Deny it in several places, not to mention that
applications without decent manifests will be virtualized if they try.

Second of all, who says there exists a C: at all?
I've had lots of software break spectacularly when I had my OS on E:.

--
Lars Viklund | [hidden email]
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [filesystem] home_directory_path

Alexander Churanov
In reply to this post by Stewart, Robert
2010/10/20 Stewart, Robert <[hidden email]>:
> Common knowledge.  Windows is a single user system with multi-user functionality overlaid.  All users have full access to C:\.

I'm afraid that isn't true. Search using google for "vista access to C drive".

> No directory should be overpopulated, as a rule, because directory searches take increasingly long as the number of files grow (though some filesystems are less hampered than others) and because directory listings become unwieldy to grok visually.  The home directory is more important to not over-populate because it is already the location of dot files and all subdirectories leading to other content.  Adding user-generated content to the necessary content makes it harder to use as the jump point to all user content, whether user-generated or locally installed applications/libraries.

Usually users do not put more that a decade of directories in the
home. This is far less than the number of dot files that are already
there.

> I hope these points help to convince you that Filesystem should not return $HOME by default.  It is better to leave that decision to the client code and a convenience default will encourage use of that default, so it ought not to be a default that leads to poor practice.

To my mind saving user-visible files in ${HOME} is an acceptable
practice. The absence of function for obtaining a default folder where
to save documents will kill cross-platformness for this feature.

Alexander Churanov
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [filesystem] home_directory_path

Marsh Ray-3
In reply to this post by John B. Turpish
On 10/20/2010 08:14 AM, John B. Turpish wrote:
> +1
> The fact that I see it differently but understand some of the
> arguments being made here suggests to me that it should be left up to
> the application developers and not guess at it in Boost.

+1

We need to face the fact that the concept of "home directory" simply
doesn't exist with common semantics across the various platforms.

Trying to make consistent generalizations out of cross-platform
mismatches will simply lead to a lot of uninteresting discussion that's
no doubt been gone over for every cross platform portability layer
already made. IMHO Boost has more interesting problems to go after.

The concept of "temp directory" seems to work well enough though. Let's
be content with that.

- Marsh
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [filesystem] home_directory_path

Christian Holmquist
In reply to this post by Alexander Churanov
On 20 October 2010 11:42, Alexander Churanov <[hidden email]>wrote:

> 2010/10/20 Stewart, Robert <[hidden email]>:
> > Common knowledge.  Windows is a single user system with multi-user
> functionality overlaid.  All users have full access to C:\.
>
> I'm afraid that isn't true. Search using google for "vista access to C
> drive".
>
>
>
If we disregard historical reasons for why things behave as they do on
Windows, to me it's quite clear that C:\ (or the OS root drive) is not each
user's $HOME path. They may or may not have write access outside their own
My Documents (or Users) but that doesn't change anything. You can setup a
NIX system that way too probably, allowing full access everywhere. $HOME
would remain however.

Are those people advocating for $HOME on Windows to be anything else than My
Documents really Windows users? I've been trough development of fixing
pre-Vista developed applications to work, and the times where one could just
ignore access rights on Windows is long gone.
IMO Boost.Filesystem should follow best practices for each supported
platform, and using C:\ as default user folder or the obscure USERPROFILE is
IMO not good practice on Windows.

Christian
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [filesystem] home_directory_path

Stewart, Robert
In reply to this post by Chad Nelson-2
Chad Nelson wrote:
>
> Automatically saving user-generated content into it is
> wrong. Returning it from that function might not be, if there's
> no better logical candidate.

That distinction is interesting, but is it necessary that the function have a default on POSIX systems?  We've suggested ideas on how that could be set by the client, according to some local policy without Filesystem having to impose an opinion on what is most appropriate.

>  Since the requested directory *is* explicitly for
> user-generated content, presumably most programs would use the
> returned path to pop up a load/save dialog to the user (who
> would then manually navigate to his preferred subdirectory for
> his documents), or would append their own subdirectory names to
> it before silently saving files.

Saving in or under My Documents is not so unlike saving in or under one's home directory.  Perhaps I'm too stridently against content being put into the home directory thus not wanting to encourage that by making it the default.

> So long as the behavior is documented, I don't think it would
> be a problem. As a developer it's what I'd want, because if I
> had to write OS-specific changes to my program to make it work,
> it would be a lot less useful to me.

Your notion of an app saving the user's last directory is reasonable, meaning that the My Documents directory, or its equivalent, would be used only when there is no user-driven default available.  Since the home directory is at least the parent of the directory in which the user would want to put a file, its use in that scenario is not unreasonable.

If Filesystem offered a means to override the path returned by home_directory_path() (or however it's spelled), then those that prefer something else can set it and those that prefer the home directory can leave the default.

BTW, it would be better to refer to the result as the "documents directory" instead of the home directory since there isn't a good notion of home directory on Windows.  Thus, documents_directory_path() or get_os_path(path_documents) (or something along those lines).

_____
Rob Stewart                           [hidden email]
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.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [filesystem] home_directory_path

Stewart, Robert
In reply to this post by Christian Holmquist
Christian Holmquist wrote:
> On 20 October 2010 11:42, Alexander Churanov
> <[hidden email]>wrote:
> > 2010/10/20 Stewart, Robert <[hidden email]>:
>
> > > Common knowledge.  Windows is a single user system with multi-user
> > > functionality overlaid.  All users have full access to C:\.
> >
> > I'm afraid that isn't true. Search using google for "vista
> > access to C drive".

Well, not being a Vista user (or Windows 7 user, for that matter), I've never run into that restriction.  Given XP's market share, it's an awfully good proxy for Windows generally, however.

> If we disregard historical reasons for why things behave as
> they do on Windows, to me it's quite clear that C:\ (or the OS
> root drive) is not each user's $HOME path. They may or may not
> have write access outside their own My Documents (or Users) but
> that doesn't change anything. You can setup a NIX system that
> way too probably, allowing full access everywhere. $HOME would
> remain however.

No one ever suggested that C:\ was a user's home directory.  Quite the reverse.  I suggested that making the home directory be the equivalent of My Documents was tantamount to using C:\ instead of My Documents.

> Are those people advocating for $HOME on Windows to be
> anything else than My Documents really Windows users?

There was a suggestion of using the %USERPROFILE% directory, I think, and of the Desktop, but the consensus has been largely to use My Documents.

> IMO Boost.Filesystem should follow best practices for each
> supported platform, and using C:\ as default user folder or the
> obscure USERPROFILE is IMO not good practice on Windows.

You're fighting yourself on the C:\ idea and I don't think there was strong support for USEPROFILE or Desktop, so I think most everyone agrees with you to use My Documents on Windows.  The thornier issue is what to use on POSIX systems.

_____
Rob Stewart                           [hidden email]
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.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [filesystem] home_directory_path

Giovanni Piero Deretta
In reply to this post by Christian Holmquist
On Wed, Oct 20, 2010 at 7:11 PM, Christian Holmquist
<[hidden email]> wrote:

> On 20 October 2010 11:42, Alexander Churanov <[hidden email]>wrote:
>
> Are those people advocating for $HOME on Windows to be anything else than My
> Documents really Windows users? I've been trough development of fixing
> pre-Vista developed applications to work, and the times where one could just
> ignore access rights on Windows is long gone.
> IMO Boost.Filesystem should follow best practices for each supported
> platform, and using C:\ as default user folder or the obscure USERPROFILE is
> IMO not good practice on Windows.
>

USERPROFILE on my Windows machine points to <root>\Users\<username>.
This is pretty much the only dir by default where my normal user id
has write permission. This is where Documents, Desktop, Favorites,
Appdata user directories are. Is there any reason *not* to use
USERPROFILE on Vista or later?


--
gpd
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [filesystem] home_directory_path

Stephan T. Lavavej-2
[Giovanni Piero Deretta]
> USERPROFILE on my Windows machine points to <root>\Users\<username>.
> This is pretty much the only dir by default where my normal user id
> has write permission. This is where Documents, Desktop, Favorites,
> Appdata user directories are. Is there any reason *not* to use
> USERPROFILE on Vista or later?

I haven't followed this thread closely, but I know that this kind of thing is tricky.

If someone could explain, very concisely and precisely, what kind of directory is desired, I can forward the question to our Windows API internal mailing list. Hopefully, someone knowledgeable about the Windows API (i.e. not me) will reply with what directory you want, and exactly how to get it (I know that both can be tricky; the answer may also vary between OS versions).

Stephan T. Lavavej
Visual C++ Libraries Developer
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [filesystem] home_directory_path

Bjørn Roald
In reply to this post by Stewart, Robert
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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [filesystem] home_directory_path

Christian Holmquist
In reply to this post by Giovanni Piero Deretta
On 20 October 2010 13:53, Giovanni Piero Deretta <[hidden email]>wrote:

> On Wed, Oct 20, 2010 at 7:11 PM, Christian Holmquist
> <[hidden email]> wrote:
> > On 20 October 2010 11:42, Alexander Churanov <
> [hidden email]>wrote:
> >
> > Are those people advocating for $HOME on Windows to be anything else than
> My
> > Documents really Windows users? I've been trough development of fixing
> > pre-Vista developed applications to work, and the times where one could
> just
> > ignore access rights on Windows is long gone.
> > IMO Boost.Filesystem should follow best practices for each supported
> > platform, and using C:\ as default user folder or the obscure USERPROFILE
> is
> > IMO not good practice on Windows.
> >
>
> USERPROFILE on my Windows machine points to <root>\Users\<username>.
> This is pretty much the only dir by default where my normal user id
> has write permission. This is where Documents, Desktop, Favorites,
> Appdata user directories are. Is there any reason *not* to use
> USERPROFILE on Vista or later?
>
>
>
On Windows 7/Vista USERPROFILE seems definitely right, I apologize.
At work on XP with some kind of networked domain storage thing for My
Documents, C:\Documents and settings\<username> seems a little like bogus,
but maybe the domain/installation is just ill-configured, and doesn't serve
as a good example.

Christian
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [filesystem] home_directory_path

Chad Nelson-2
In reply to this post by Stewart, Robert
On Wed, 20 Oct 2010 14:45:55 -0400
"Stewart, Robert" <[hidden email]> wrote:

>> Automatically saving user-generated content into it is
>> wrong. Returning it from that function might not be, if there's
>> no better logical candidate.
>
> That distinction is interesting, but is it necessary that the function
> have a default on POSIX systems?  We've suggested ideas on how that
> could be set by the client, according to some local policy without
> Filesystem having to impose an opinion on what is most appropriate.

Necessary, no. But it would simplify using it if it did. Then, if I
didn't need anything different from the default (as I doubt I ever
would, in this case), I wouldn't have to do anything to it in order to
port my program from one OS to the other. It would just work,
automatically. Without a default, it's another thing I'd have to think
about.

>> Since the requested directory *is* explicitly for user-generated
>> content, presumably most programs would use the returned path to pop
>> up a load/save dialog to the user (who would then manually navigate
>> to his preferred subdirectory for his documents), or would append
>> their own subdirectory names to it before silently saving files.
>
> Saving in or under My Documents is not so unlike saving in or under
> one's home directory.  Perhaps I'm too stridently against content
> being put into the home directory thus not wanting to encourage that
> by making it the default.
If Linux users were like the majority of Windows users, I'd agree
wholeheartedly with your position. But the majority of Linux users are
still power users, at the very least. If they save something in their
home directory, it's because they explicitly want it there.

(As an aside, I've only got five non-dot files in my home directory,
all deliberately placed there for logical reasons.)

>> So long as the behavior is documented, I don't think it would
>> be a problem. As a developer it's what I'd want, because if I
>> had to write OS-specific changes to my program to make it work,
>> it would be a lot less useful to me.
>
> Your notion of an app saving the user's last directory is reasonable,
> meaning that the My Documents directory, or its equivalent, would be
> used only when there is no user-driven default available.  Since the
> home directory is at least the parent of the directory in which the
> user would want to put a file, its use in that scenario is not
> unreasonable.
Yes, exactly.

> If Filesystem offered a means to override the path returned by
> home_directory_path() (or however it's spelled), then those that
> prefer something else can set it and those that prefer the home
> directory can leave the default.

Sounds good to me. :-)

> BTW, it would be better to refer to the result as the "documents
> directory" instead of the home directory since there isn't a good
> notion of home directory on Windows.  Thus, documents_directory_path()
> or get_os_path(path_documents) (or something along those lines).

Certainly. There was also some discussion about including the APPDATA
directory in Windows, which would also map to the user's home directory
under *NIX, and which could cause some confusion otherwise.
--
Chad Nelson
Oak Circle Software, Inc.
*
*
*


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [filesystem] home_directory_path

Stewart, Robert
In reply to this post by Bjørn Roald
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                           [hidden email]
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.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [filesystem] home_directory_path

Ulrich Eckhardt-2
In reply to this post by Jeff Flinn
On Monday 18 October 2010 16:58:31 Jeff Flinn wrote:
> Windows NT and above have the "USERPROFILE" environment variable. Using
> this would be the easiest to use. But I've seen discussion that this may
> not always be properly defined, in particular if the user has reset
> their home directory to a non-system drive. I haven't tracked down it's
> availability on WinCE. Does anyone have experience with this platform?

MS Windows CE doesn't have environment variables at all.

> There is the windows GetUserProfileDirectory api function also available
> since NT4. This is in the Userenv.lib/dll, obviously adding a link
> dependancy.

Concerning CE, I don't think this will work there. The point is that CE is
essentially a single-user system. There is an equivalent though, for the
user's files.

> How are these sorts of system link dependencies handled?
> Through bjam? Or is it acceptable/better to use #pragma
> comment(lib,"Userenv.lib")?

Using that #pragma is not portable, otherwise I would prefer it.

Uli
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [filesystem] home_directory_path

John B. Turpish
In reply to this post by Chad Nelson-2
On Wed, Oct 20, 2010 at 6:44 PM, Chad Nelson
<[hidden email]> wrote:
> On Wed, 20 Oct 2010 14:45:55 -0400
> "Stewart, Robert" <[hidden email]> wrote:
> wholeheartedly with your position. But the majority of Linux users are
> still power users, at the very least. If they save something in their
> home directory, it's because they explicitly want it there.

This isn't meant as a disagreement, since you do use "majority".
However, not all Linux users are power users. My wife uses Linux, and
I doubt she could tell you the path to her $HOME much less what it's
supposed to be for. I have a friend who is a complete idiot, and he
uses Linux.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
1234