Re: [boost] Re: Re: Re: [filesystem] status() if neither filenordirectory?

From: Mathew Robertson (mathew.robertson_at_[hidden])
Date: 2005-05-08 21:05:35

> >>> 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).

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.

Mathew