From: Peter Dimov (pdimov_at_[hidden])
Date: 2005-03-31 08:10:58
Beman Dawes wrote:
> If the is_* functions return false, rather than throwing, then
> testing for the negative of a is_* function becomes unreliable.
On the contrary, it becomes reliable. It's currently undefined.
> Does !is_directory( "foo" ) mean that "foo" is a file, or is is just
!is_directory( "foo" ) means that "foo" is not a directory, i.e. directory
operations on "foo" will fail.
It cannot be used as a substitute for "is a file", for any reasonable
definition of "is a file".
> The programmer would have to write exists("foo") &&
> is_accessible("foo") && !is_directory("foo"). That could be
> simplified by providing an is_file() function (as suggested by Jeff
> Garland recently), but then we have to define exactly what a file is.
> Is a socket a file? Is a device a file? Or what POSIX calls a "regular
> file"? How does that translate to Windows?
It depends on your definition of "file". In general, is_X( "foo" ) should
return true when "foo" can be treated as a X, that is, you can call
X-related functions on "foo".
One example could be is_data_stream( "foo" ), which would mean that you can
fopen( "foo" ) and then fread it. Or is_seekable_stream, which also includes
Note that on platforms where a directory can be opened with fopen,
is_directory and is_data_stream will both return true.
The translation of is_regular_file to Windows is trivial, if a bit
time-consuming: enumerate all properties of a POSIX regular file (that are
observable to us); everything that matches this description is a "regular
file", not only on Windows, but on an arbitrary file system.