[boost] Fw: boost::filesystem file restrictions

From: Dave Gomboc (dave_at_[hidden])
Date: 2003-08-15 23:07:09

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

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

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