Re: [boost] Re: [Filesystem] i18n

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

!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 
fseek.

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.