RE: [boost] Re: the first version of abstract path manipulation c lass (interface)

From: Stewart, Robert (stewart_at_[hidden])
Date: 2002-01-30 08:13:43

From:	John Maddock [SMTP:John_Maddock_at_[hidden]]
> 
> BTW the situation is much more complex that one would think - case
> sensitivity is a property of the pathname itself, and not the platform on
> which it is running.
> 
> Consider that NT does support case sensitive filesystems - in which case
> the case sensitivity is dependent upon the drivename (see
> GetVolumeInformation).  However on unix systems you can mount a case
> insensitive filesystems within a case sensitive one, throw in symbolic
> links and the whether comparison is case sensitive changes with each part
> of the pathname: so with /foo/bar the foo part may be case sensitive and
> the bar part case insensitive.

Wow!  You're right.  I hadn't thought of that.  I don't know that there is
any good way to deal with this.  I shouldn't think we'd want a pathname
manipulation class to be accessing the filesystem to check on the case
sensitivity of each path component; that will get pretty nasty.

I'd be inclined to say that you create an object to manipulate a pathname
with or without case sensitivity, and leave it to the programmer to decide
how many such objects to use and in what combination.  IOW, the programmer
could check the filesystem for case sensitivity, create pathname objects for
each portion of the path where that sensitivity differs, and manipulate that
set of objects as a logical whole.  That puts the onus on the programmer and
not the pathname class.

Perhaps that means we need a simpler, lower level class that manipulates a
pathname or some portion of one, using a single case sensitivity/filesystem
policy, and another, higher level class, that aggregates the simpler objects
to create a logical pathname object that spans filesystems.

Rob
Susquehanna International Group, LLP
http://www.sig.com