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

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
i.e
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
interface.

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

_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost