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

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-03-04 12:03:38

At 03:08 AM 2/26/2002, Jan Langer wrote:

 >> >>How absolute() does its job internally is an implementation detail;
 >that
 >> >>isn't a good argument for exposing getcwd/chdir.
 >> >
 >> >what should absolute() do? it isn't mentioned in the requirements as a
 >> >function.
 >>
 >>Because I'm not sure if it is in fact a requirement.  It would take a 
path
 >>and return an absolute path (which might in fact be the same string).
 >
 >this function would imply current_directory (). if you call absolute
 >("") you should get the current directory but you cannot set it. i would
 >prefer supporting either both or none.
 >
 >ps: i changed the code so that the directory_iterator changes an
 >empty string to "." in its ctor.

At 08:43 AM 2/26/2002, Jan Langer wrote:

 >>several questions which came up during writing:
 >  - how can i delete the current directory? remove ("");
 >    or in other words: should the posix-impl replace all occurences of
 >"" by "."?

I've been thinking a lot about Jan's two messages above, and I'm convinced 
he has identified a serious weakness.  We don't want any trap doors that 
allow access to the current working directory.

(Rationale: "current working directory" is in effect a global variable. For 
why that is a serious problem, put "global variables considered harmful" 
into Google.)

OTOH, we do want programs like "ls" or "dir" to be able to supply a default 
starting point in the directory tree.

The solution is to remember that while global variables are disastrous, 
global constants are relatively harmless, at least if initialization can be 
dealt with.

The initial_directory() function below is the closest I've been able to 
come to that ideal. Comments appreciated.

I've also included root_directory() and some TODO items, for comment.

The upshot of all this is that the answer to Jan's question about the 
meaning of "" as a path is either:

   (1) An error.
   (2) initial_directory().
   (3) root_directory().

(3) seems totally wrong a lot of the time.  (2) is sometimes the intent, 
but it might also be simply an error.  (1) is safest; it means you have to 
explicitly write initial_directory() if that is what you mean. Programs 
would read more explicitly.  My guess is that (1) would detect a fair 
number of errors at very little user cost.  But we need to figure out if "" 
has some well defined meaning (as a pathname, not as a command line 
argument) on certain platforms.

Comments?

--Beman

template< typename CharT >
std::basic_string<CharT> initial_directory();

Effects: The first time called, stores an absolute directory path.
The path is determined as if by the following:
   If possible, the path of the initial working directory
   when main() was called. Otherwise, if possible, the current
   working directory. Otherwise, root_directory().
Returns: The stored path.
Rationale for not simply specifying the return as "initial working
directory when main() was called": That directory isn't known on all 
platforms; indeed there may not even be a concept of "current working 
directory". The semantics are chosen to come as close to that as  possible.
Note: It would be a good practice in a program dependent on
initial_directory() to call it immediately on entering main().
That protects against a called function altering the current working 
directory (using a native platform function) and then calling 
initial_directory().

template< typename CharT >
std::basic_string<CharT> root_directory();

Returns: The absolute path for the file system's root directory.
Note: The value of the root directory string is specified in terms
of its effect if passed to a basic_directory_iterator constructor.
The resulting iterator would iterate over all the entries in the real (in 
the case of POSIX) or virtual (in the case of Windows) directory. On some 
platforms (Windows), the root directory will be read only, and all the 
entries in the root directory will have funny names (a:/, b:/, c:/, etc.)

TODO: That definition needs to be expanded so root_directory() works 
correctly and portably in path composition and other uses.

TODO:  We need a safe way to turn a relative path into an absolute path. 
Perhaps absolute( relative-to, path ) which returns path if it is already 
absolute, or path( relative-to, path ) if path is relative.

TODO:  We need an overall review of what "" means as a path arg in all file 
system functions (not just the ones in this header.)

TODO:  Two argument path composition is hopeless in trying to write real 
code. Need n-argument.  (I realize that argues for a path composition type 
which could overload operator+ appropriately. I'm not thinking of replacing 
the string type in all path args, just the possibility of a path 
composition type used only when composition is needed, with an automatic 
conversion to string.

--- end ---