Re: Design for a file system library

From: dylan_nicholson (dylan_nicholson_at_[hidden])
Date: 2002-03-14 16:50:20

--- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
> At 04:45 PM 3/12/2002, dylan_nicholson wrote:
> 
>  >--- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
> 
>  >> None of those are "OK".  They are all dangerous in proportion to
>  >the
>  >> likelihood that they change unexpectedly.
>  >>
>  >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.

> 
> Because it is better to begin without relying on a less safe 
> practice.  Then, if it appears it really is necessary, provide it 
in some 
> ugly way that discourages use and/or alerts potential users that 
there is a 
> problem.  For example, the nothrow version of 
> boost::filesystem::remove().  Wrapping an unsafe practice in a 
> hard-to-misuse class is sometimes a good approach, too.
> 
Another good example - remove changes "global data" - ie the 
existence of a file.

>  >>
>  >Indeed.  Just yesterday I wrote a simple utility using nothing but
>  >standard C++ and a few filesystem calls.  And guess what - it 
needed
>  >to change and restore the working directory because it executed
>  >another application (using system), which had to be run in a
>  >particular directory to work correctly.
> 
> Thanks. That is the kind of example we need.  If it is the only 
example 
> anyone can come up with, we can provide a version of system() which 
takes 
> the directory as an argument.  If the need is more commonplace, we 
can 
> provide a forwarding class which pushes/pops the current directory.
> 

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.

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

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

Dylan