RE: [boost] boost/filesystem/directory.hpp is_file()

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-03-21 09:49:23

At 05:42 AM 3/21/2002, Ross Smith wrote:

 >-- Dividing everything into "is_directory()" vs "is_file()" doesn't work
 >on Unix, where there are any number of other things a file system object
 >might be (devices, pipes, etc.).

Hum... That isn't my understanding. "Everything in the UNIX system is a 
file." First sentence of Chapter 2, The File System, Kernighan and Pike's 
The UNIX Programming Environment. Section 2.7 makes it very clear they view 
devices as files.

Since there is confusion, we need to be more specific.  I'd suggest:

A directory entry, whether identified by a path or a directory_entry 
returned by a directory iterator, represents either a file or a 
directory.  If an operating system normally views devices, pipes, sockets, 
connections, or other operating system objects as files (as does UNIX), 
then these will be treated by the file system library as files, will be 
found by directory iteration, and can be named in paths.  If the operating 
system does not view such objects as files, the file system library will 
not treat them as files, directory iteration will not find such objects, 
and it is invalid to name them in paths except in implementation defined 
usages.

At 02:51 AM 3/21/2002, Keith Burton wrote:

 >There is a requirement for is_file() if there are any 'things' visible
 >in the filesystem ( e.g. returned by directory iterators ) where
 >is_directory() is false but other xxxx_file functions would not work
 >correctly.   Sockets and printers have already been mentioned as
 >possibilities.

I see your point.  If we have functions which don't work on certain things, 
we have to be able to tell if a path is one of those things.

If we accept the definition of directory and file given above, is_file() 
isn't an absolute requirement,.

OTOH, it has been suggested the current semantics are sometimes too strict.

For example, it is painful to so often have to write:

    if ( exists(path) && is_directory(path) ) { /* do something */ }

If we change the semantics of is_directory() to:

    return exists(path) && is a directory;

then code gets easier to write but now !is_directory() doesn't mean it's a 
file (since it could just not exist).  So we would then need is_file(), 
with exists(path) && !is_directory(path) semantics.

--Beman

--Beman