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
news:066f01c5543b$96a11570$a901000a_at_mat...
>> >>> 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.

--Beman


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk