Re: [boost] Re: Re: Re: Re: [filesystem] status() ifneitherfilenordirectory?

From: Mathew Robertson (mathew.robertson_at_[hidden])
Date: 2005-05-09 20:08:07

> >> > I'm only partially convinced. How useful is knowing that you can 
> >> > ifstream a
> >> > directory? The only cases I can think of are so system specific that I 
> >> > have
> >> > trouble seeing them in the context of Boost.Filesystem.
> >>
> >> ReiserFS version 4 supports opening a directory as a file. eg:
> >
> > FreeBSD and Solaris both allow opening a directory (read-only) with
> > open(2) and reading from it with read(2) on their default FS types.
> >
> > If you know the format of the directory and want to write a non-portable
> > app that reads it directly you could use an ifstream to do so, in
> > theory.
> 
> Sure, but it seems like you can only use that facility on a system you 
> already have prior knowledge about. Part of that knowledge could come from 
> ::stat(), either directly or wrapped in a call to 
> boost::filesystem::status().

Yes that knowledge _could_ come from status(), but for platforms that dont support the named property, the implementation should return something useful as a fallback.

However,  is_blah()  should "do the right thing" on platforms which dont support 'blah'

> But if stat() doesn't report both S_ISDIR and S_ISREG true at the same time, 
> there isn't any way to practically implement status(), even if you buy the 
> argument that reporting both would be desirable.

sure there is...  dont use stat()  -  use boost::filesystem::status()  then have status() return something that generic code can work with.  And the return code from status() doesn't _have to_ be the actual bitmap value returned from  S_ISDIR && S_ISREG  ->  status() can choose to remap this return value into something platform agnostic.

If a developer chooses to use stat() - which is not always platform agnostic - thats their own fault.  One purpose of using boost::filesystem is to abstract the platform inconsitancies.

Mathew