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

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-08-13 08:19:31

At 04:44 AM 8/13/2002, Anthony Williams wrote:

-----Original Message-----
From: Anthony Williams [mailto:anthwil_at_[hidden]]
Sent: 13 August 2002 09:28
To: Williams, Anthony [PAI01:3497:EXCH]
Subject: [boost] Re: [filesystem] documentation nitpick

  > > From:      Carl Daniel[SMTP:CPDANIEL_at_[hidden]]
  > > Sent:      Tuesday, August 13, 2002 12:13:07 AM
  > "Thomas Witt" <witt_at_[hidden]> wrote in message
  > news:200208121937.41760.witt_at_ive.uni-hannover.de...
  > > Have a look at the attached program. Compile (SUBSYSTEM:console) and 
run.
  > It
  > > will create two files with filenames differing only in case. BTW this 
only
  > > works for NTFS (i.e. not for network shares).
  >
  > Ah yes - FILE_FLAG_POSIX_SEMANTICS.  That does raise an interesting 
question
  > though:
  >
  > This flag is provided by the Win32 API to allow programs such as
  > backup/restore programs to properly process directories containing 
files
  > created by POSIX programs, which may have names differing only in case. 

  >
  > Should the filesystem library provide access to such subtleties?
  >
  > I'd be inclined to say no, but others might disagree.

I'm here to disagree --- we certainly ought to allow access to such files 
with the filesystem library. I think it is important that the filesystem 
library allows us to manipulate every manipulatable file on a given system. 
You might want to make it an option, though --- pass in a 
"case-insensitive" flag when constructing a path, perhaps.

Anthony,

The Filesystem Library is aimed at those wishing to write portable 
programs.

Various operating systems provide a wide range of really wonderful files; 
generation (versioned) datasets, partitioned datasets, indirect (dd) 
naming, etc, etc.  Remember too that unlike Windows and POSIX, both of 
which provide a single unified view of their filesystems, some operating 
systems provide multiple views, each with their own API's, grammar, naming 
rules, etc.  I think z/OS provides something like six views ("view" is my 
nomenclature; I forget what they call the views.)

A program which wishes to be able to "manipulate every manipulatable file 
on a given system" is going to be tied to that operating system, so why not 
just use the native operating system's API?

So I agree firmly with Carl - the Filesystem Library should not try to 
provide access to the subtleties of each operating system.

--Beman