Re: [boost] Re: Design for a file system library

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-03-15 15:35:24

At 04:50 PM 3/14/2002, dylan_nicholson wrote:

 >>  >Then why are you singling out current directory as something
 >>  >programmers shouldn't be able to access/change easily?
 >>
 >> Because that's the library I'm working on.
 >
 >But the library you're working on *does* allow you to determine the
 >existence/properties of a file.  That is actually far more likely to
 >change "unexpectedly" than the current directory - at least the
 >current directory can't be changed by anything else other than the
 >current process.

Yes, that's a serious problem. It is one of the reasons to be so picky 
about specifying the error conditions which can cause exceptions to be 
thrown.

 >I like the push/pop idea.  But I gave an example earlier (using
 >Win32's GetOpenFileName) where you need to determine what the current
 >directory has been changed to by a library call.

If we come up with portable programs that need a feature that can added in 
a portable manner, I'll give it serious consideration.  But if the need is 
solely to interface with a platform specific function like GetOpenFileName, 
just use the platform specific GetCurrentDirectory.

 >> Questions about your example above:
 >>
 >> What is the expectation for portability if the O/S has only a flat
 >(single
 >> directory) file system?
 >>
 >Just the same as if the O/S had no filesystem :o)

One of my design targets is a system (perhaps a small embedded system) 
which has a flat (single directory) file system.  I'd like as much as 
possible of a filesystem library to work in that environment.

 >>What is the expectation for portability if the O/S supports
 >>hierarchical directories, but has no concept of "current directory"?
 >>
 >
 >Any OS-interfacing library has essentially an platform-dependent
 >implementation.  If such a platform really did exist then even
 >fstream::open/fopen etc would need a method of telling the OS how to
 >open an incompletely specified filename, meaning the standard C
 >runtime library would probably have to maintain the current
 >directory.  But I think you're genuinely clutching at straws here - I
 >would be intrigued indeed if you really know of such an OS.

That's a good question.  I'm having trouble finding out about some of the 
big mainframe systems like OS/390.  Even if some of those monster systems 
(which often run numerous O/S's in different virtual machines) still run 
older O/S, does anyone write new programs for them in C++? Does anyone 
reading this know?

 >It kinda seems that from other posts on this subject you are somewhat
 >alone in wanting to keep the current directory away from the
 >programmer's reach - I understand your concerns but in the end the
 >library has to be useful in the "real world" as it were.

I'll add it (directly or indirectly) when and if someone comes up with an 
example of a ("real world" or not) portable problem that is poorly handled 
(or not handled at all) by a design that doesn't rely on get/set current 
directory.

--Beman