Re: FW: [boost] Re: [filesystem] documentation nitpick

From: Anthony Williams (anthwil_at_[hidden])
Date: 2002-08-14 07:43:04

On Tuesday 13 August 2002 17:43, Thomas Witt wrote:
> On Tuesday 13 August 2002 15:19, Beman Dawes wrote:
> > 
> > So I agree firmly with Carl - the Filesystem Library should not try to 
> > provide access to the subtleties of each operating system. 

For the example you gave of an OS with 6 "views" on the filesystem, which
"view" would you expect boost::FileSystem to use? Is there an obvious default,
or would the user have to supply an option?

I can envisage that there is scope for an OS-specific flag: much as we have
OS-specific path names in general, some OSes (including Windows NT and the OS
you mentioned) have more than one set of semantics for accessing files, and
therefore the user ought to be given the option of choosing which semantics to
apply.

> Thats what I think. Though there is a little quirk here. Depending on the
> implementation the following situation can arise. The directory_iterator
> will list two different files that can't be accessed independently. This
> makes me feel a little uncomfortable as in many cases the user of the
> library will not have influence on the filesystem the application runs on.
> Might be worth a note in the documentation.

I've just been playing with the files generated by the posted "ntfs.cpp" ---
Justanotherweirdfile and jUstanotherweirdfile. Any access to the files from
non-POSIX-aware apps (i.e. just about everything) references
Justanotherweirdfile, whatever case combination you use (even
jUstanotherweirdfile, which is an exact match for the other file).

So not only is the file jUstanotherweirdfile not accessible, all accesses are
silently redirected to Justanotherweirdfile. It therefore seems to me that the
FileSystem library ought to be aware of this, since part of its intent is to
be used for scripting --- we don't want an automatic script to process the
same file twice, when reading a directory, for example.

> Just as an idea can the implementation try case sensitive access first
> and resort to case-insensitive in case of failure? What does this mean 
> performance wise.

I can't find a single API that can handle the POSIX_SEMANTICS flag, other than
CreateFile, so actually there isn't much we can do, except be aware that there
might be two (or more) files with the same name (when considered
case-insensitively) in a given directory, and that any access to any of them
will access the first.

This strikes me as a bit of a flaw in the Windows API, but there you go. I
presume that applications running under the POSIX subsystem will be able to
access the files OK, but you never can be sure.

Anthony