Boost logo

Boost :

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

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

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.



Boost list run by bdawes at, gregod at, cpdaniel at, john at