[boost] Re: Fw: boost::filesystem file restrictions

From: David Abrahams (dave_at_[hidden])
Date: 2003-08-15 23:36:03

Dave Gomboc <dave_at_[hidden]> writes:

> ---> 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.
> ->
> -> I see you don't perceive changing a removable medium with changing the
> -> "state" of the machine (interesting perception of state).
>>
>> That changes the physical file(s) associated with certain paths, just
>> like deleting and creating files or creating symlinks.  It does not
>> change where those paths refer to in the filesystem.
>
> I think lack of agreement of a common vocabulary may be hampering the
> discussion of boost::filesystem, and that this might stem from different
> conceptual notions of what we are speaking of.
>
> For example, while it is possible to think of all drives on an MS Windows
> machine as being part of a single filesystem, an individual using NTFS on
> C:, FAT32 on D:, FAT16 on E:, and FAT12 on A: reasonably would not.  It is
> unquestionable that NTFS and FAT are different filesystems.  

Yes, that's a completely different meaning for the word "filesystem".
It refers to a low-level data format and its associated
representational power (e.g. allows links, max filename length, case
sensitivity, etc.)

Does one not use the same OS API and shell interface for interacting
with NTFS and FATXX?  Certainly, the boost::filesystem API is agnostic
to the flavour of filesystem underlying any path.  It's fine to talk
about every disk with a unique format as being a separate filesystem
but if it has no meaning for the library it's completely irrelevant.

> Now, one can choose to use NTFS for both C: and D:, but that does
> not make C: and D: together a single filesystem.  On UNIX and
> UNIX-like systems, it is quite natural to have multiple drives with
> possibly different filesystems and to think of their conglomeration
> to be a single filesystem, but this is just a UNIXism.  

No, it's a consequence of having a single interface for working with
all files in the system.

> It is neither natural for members of other communities (MS Windows,
> VMS, etc.) to view file access in this manner, nor desirable to
> force them to do so.

Weird.  I'm basically a Windows user.

> Other comments (e.g. re: "basename") also served to remind me that
> this entire discussion would best have taken place during the Boost
> review for the filesystem library.

Yes; I wasn't paying attention then.

> (Indeed, it would surprise me if "basename" was not both brought up
> and criticized during the review, notwithstanding POSIX's
> endorsement, but the issue doesn't interest me enough to go and
> search for it.  FWIW, I'm happy with root/branch/leaf.)  

Sure, I like those terms just fine as long as the doc is defining them
up front and explaining their significance.

> Mainly I think that if boost::filesystem was deeply flawed, it would
> not have been accepted to Boost.  It is not as if some startling
> new, unforeseen issues have arisen that Beman and others had never
> considered before.  Current usage is clear and not particularly
> problematic, so I feel it ought to be left well enough alone.

I don't know if it's deeply flawed or not, but its design and
presentation combined to make it problematic for me.  Some questions
about the central role of "portable" paths still need to be answered
for me to feel comfortable using it.  Maybe I'll get used to it, or
maybe I'll have to switch.

> As a tangential comment, I agree that boost::filesystem should be
> favoured over boost::fs in sample code in the documentation.  I
> would also suggest that said documentation should contain the
> #include lines to include the library within the documentation's
> sample code, at least for the very first example.  Fortunatley, it
> would appear that at the very least some important improvements to
> the documentation have been made (or will be made) as a result of
> the discussion.
>
> Apologies in advance if the quote at the top is too long -- I
> thought it was best left in here.  On first send, the email was
> apparently automatically rejected for this reason, so I altered the
> quoting characters.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com