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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk