[boost] Re: Re: Re: Re: [filesystem] status() if neitherfilenordirectory?

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