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