Boost logo

Boost :

From: Keith Burton (kb_at_[hidden])
Date: 2002-03-22 04:42:46

1) is_file() etc.

Only a true result from these functions has an unambiguous meaning
because of the exists problem and therefore they should all be paired
is_directory() / is_file()
is_read_only() / is_writeable()

This implies other options such as is_socket() for filesystems that
support them but I do not believe that these should be in the general

2) 'remove' exceptions

The function for any operation should not generate an exception if the
post condition is definitly true. This applies to remove_xxx and
create_directory but cannot apply to move_file( src, dest ) where src
does not exist and dest does as there is no way to determine whether
dest contents are as intended.

Keith Burton


-----Original Message-----
From: boost-admin_at_[hidden] [mailto:boost-admin_at_[hidden]]
On Behalf Of Beman Dawes
Sent: 21 March 2002 14:49
To: boost_at_[hidden]; boost_at_[hidden]
Subject: RE: [boost] boost/filesystem/directory.hpp is_file()

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
The UNIX Programming Environment. Section 2.7 makes it very clear they
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,
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
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
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

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
file (since it could just not exist). So we would then need is_file(),
with exists(path) && !is_directory(path) semantics.



Unsubscribe & other changes:

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