ansi c and directories

[johnathan.tainter]

In article <225800244 at uxe.cso.uiuc.edu> mcdonald at uxe.cso.uiuc.edu writes:
>> [ discussion of varied file name conventions ]  somehow i don't
>>think there is much room left in there for a standard.  

>*****THEN WHY IS THERE SUPPORT FOR FILES IN STANDARD C???????*******

Because operations on the CONTENTS of files are sufficient common enough
to impose some very weak standards.

>You haven't even MENTIONED directories - only files.

Actually, he has described the CONTENTS of directories.  There is no well
defined set of operations which will cover these.  Some of the more
problematic things he hasn't even covered.  Like the fact that UNIX
divides its "directory" information into distinct components and can
share the i-node portion.  That some systems maintain multiple versions of
a file with version information not in the name but in the directory or
encoded in the structure of the directory.  That protection/access schemes
very widely, that interesting and wildly different archiving schemes are
encode in directories and so on.  Yes, an all things to everyone scheme could 
have been defined to cover all known (at the moment) cases, but the code
which would handle it would be wildly system dependent anyway.  At least,
dependent on which combination of schemes is chosen, almost the same
thing with the huge matrix of combinations we would get.  And it would
be problematic for porting C to a new sytem using some other never before
seen scheme.

If you mean lets put in mkdir(), rmdir() (maybe a mvdir()? lndir()?) what
does this buy us?  How useful to the common user is such a facility?
What does portability in the function interface buy you if you have to
have conditional code anyway to handle the differences in directory schemes?

>Doug McDonald

--johnathan.a.tainter--
   att!ihlpb!tainter