Boost logo

Boost :

From: Beman Dawes (bdawes_at_[hidden])
Date: 2005-05-09 07:46:24

"Mathew Robertson" <mathew.robertson_at_[hidden]> wrote in message
>> >>> A hypothetical OS that allows directories to be opened with an
>> >>> ifstream may reasonably answer true to both is_stream(p) and
>> >>> is_directory(p). Or maybe not. :-)
>> >>
>> >> I think not. Dividing the world into non-overlapping categories is
>> >> much easier:-)
>> >
>> > It's only easier until an example comes up that doesn't fit the scheme,
>> > so
>> > you are forced to invent meta-categories (also known as "hacks" in some
>> > category theory circles) such as "other". :-)
>> >
>> > "Capability bits" are cleaner. Is it openable with ifstream? file_bit.
>> > Is
>> > it iteratable with directory_iterator? directory_bit. Does it exist?
>> > !not_found_bit.
>> 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:
> opendir("/foo")
> &
> open("/foo")
> both succeed.
> This is so that you can treat a directory as a file, so that you can treat
> directory entries as 'streams' within the file (cf. win32 named
> file-streams).

After a stat("/foo", &buf), are S_IFDIR(buf.st_mode) and
S_IFREG(buf.st_mode) both true?

If so, it would be possible to implement status() to return both
directory_flag and file_flag.

But if stat("/foo", &buf) reports S_IFREG(buf.st_mode) as false, there isn't
any practical way to implement both directory_flag and file_flag set at the
same time.

> Samba 4 is intending on using this facility to map win32 stream-open's to
> real POSIX file semantics.
>> > When a socket is thrown your way, you just run it by the list and
>> > conclude
>> > that no bit needs to be set.
>> But that is about the same as having an other_flag, except that the name
>> is
>> 0 instead of other_flag. Giving it a name makes it more obvious that a
>> return from status() may not have any of the other bits set
> However it is implemented, it should be 'named' so that it is obvious to a
> person reading over the code, that the test is checking for a specific
> capability.

Agreed. That's part of the point I'm trying to make with Peter.

Thanks for the report! I would really appreciate it if you could test how
stat() is behaving in the case above.


Boost list run by bdawes at, gregod at, cpdaniel at, john at