Re: [boost] boost::filesystem file restrictions

From: Dick.Bridges_at_[hidden]
Date: 2003-08-15 12:59:42

<history comments='below'>

                                                                                                                                        
                      "Edward Diener"                                                                                                   
                      <eddielee_at_tropicso         To:      boost_at_[hidden]                                                         
                      ft.com>                    cc:                                                                                    
                      Sent by:                   Subject: [boost] Re: boost::filesystem file restrictions                               
                      boost-bounces_at_list                                                                                                
                      s.boost.org                                                                                                       
                                                                                                                                        
                                                                                                                                        
                      08/15/2003 08:35                                                                                                  
                      AM                                                                                                                
                      Please respond to                                                                                                 
                      Boost mailing list                                                                                                
                                                                                                                                        
                                                                                                                                        

David Abrahams wrote:
> Glen Knowles <gknowles_at_[hidden]> writes:
>
>>> From: David Abrahams [mailto:dave_at_[hidden]]
>>>>>     portable_path("/foo/bar") <- throws on Windows
>>>>
>>>> Not sure why this would throw, what is the purpose of
>>>> portable_path? "/foo/bar" is perfectly reasonable on Windows.
>>>
>>> It's perfectly reasonable but it doesn't have a portable meaning.
>>> It
>>> is a relative path w.r.t. the drive of the current directory.
>>
>> Almost all paths are relative w.r.t. something, the current users
>> filesystem mapping, the computer, the network.
>
> I find that somewhat compelling... but in the end it doesn't hold up.
>
>> I don't see how
>> leaving out the drive makes it less portable then leaving out the
>> computer name.
>
> It's less portable because how it is to be interpreted *with respect
> to the filesystem* can change dynamically.  Remember the name of this
> library, "filesystem"? ;->
>
> Filesystems belong to computers.  A computer's filesystem is accessed
> via an infinite tree of names (**).  How those names which correspond
> actual storage are mapped can be modified dynamically in any number of
> ways: you can have symbolic and hard links, mount drives, remote
> computers can come online or go away, non-storage devices can be
> mounted at locations in the tree etc.  The one constant is the
> structure of the tree of names which allows us to access a virtual
> location in the filesystem (as opposed to physical).
>
> A path is a set of instructions for traversing the name tree.  By any
> reasonable definition, an absolute path identifies a single virtual
> location in a filesystem's name tree, not one that can change based on
> the process state.  A path on windows that starts with '/' is a set
> of instructions which begins: "go to the root of the current
> directory path".

Correction. It does not mean that. It means go to the root directory of the
current drive. It is still not an absolute path since the current drive
changes. If one specified 'a:/', then that is an absolute path as defined
under Windows. Even if 'a:' were a removable disk, and thus could be
physically changed, it would be considered an absolute path.

</history>

I'm just a confused lurker seeking some clarification.  I thought most OSs
allowed a process filesystem to be dynamically "re-rooted" and that '/'
refers to the "current root" - whatever the OS (assuming hierarchical
filesystem[s]).  If you introduce the extra-filesystem "a:/" wrt Windows,
then why not chroot for *NIXs or the 9P messages that "re-root" the Plan 9
filesystem to a different date or file server?

I was under the impression that "/foo/bar" is a relative path wrt the
current root of any given process state.  For any given process, the
physical location of "/foo/bar" may change between points in time and, for
any two processes, the physical location of "/foo/bar" may be different at
the same point in time.

I've clearly "lost the bubble" here.  Can someone get me started in the
right direction?

TIA

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