Files & dirs: historical reasons?

[Sensei]

I was having an interesting discussion about the ANSI C and some
``weird inconsistencies '', or at least what at first sight can be seen
as an imbalance. I hope someone can satisfy my curiosity.

The standard provides means to open files associating a /path/ with a
/stream/. The standard does not provide any means to handle
/directories/. There are three streams defined by the standard, stdin
stdout stderr. Am I right?

Now, what is the reason for /not/ defining the directory counterparts
for files (something like fopen, with a directory dopen)?

We know that there exist platforms (e.g. on firmwares) where we can
hardly use ``files'' (with /paths/) while we can play with the three
standard std* /streams/. Paths of files are highly system dependent
just like directories. Files on the other hand are more likely to exist
on many platforms, or at least it seems to us.

Is there any reason? Is the standard going to change? Are directories
treated as normal files?

I know it might be a stupid question, but I'm curious about the history
behind choices :)

Thanks!

--
Sensei <senseiwa@Apple 's mail>

Research (n.): a discovery already published by a chinese guy one month
before you, copying a russian who did it in the 60s.

[Richard Heathfield]

Sensei said:

I was having an interesting discussion about the ANSI C and some
``weird inconsistencies '', or at least what at first sight can be seen
as an imbalance. I hope someone can satisfy my curiosity.

The standard provides means to open files associating a /path/ with a
/stream/. The standard does not provide any means to handle
/directories/. There are three streams defined by the standard, stdin
stdout stderr. Am I right?

Almost. The only time the Standard uses the word "path" is in a different
context completely: "Other paths to program termination, such as calling
the abort function, need not close all files properly", which is obviously
not what you are talking about! Otherwise, yes, you are correct.

Now, what is the reason for /not/ defining the directory counterparts
for files (something like fopen, with a directory dopen)?

Not all file systems have the concept of "directory" , and this includes some
prominent systems such as VM/CMS and OS390 (aka MVS). CP/M had no concept
of "directory" either. Nor did MS-DOS 1.0. Undoubtedly there are others,
too.

<snip>

[...] Is the standard going to change?

It's very unlikely.

Are directories treated as normal files?

I'm pretty sure Unix thinks of directories as merely a weird kind of file.
For example, IIRC you can fopen them. Windows sees them as being separate
beasts altogether (and you can't fopen them). And, as I said, some systems
don't have the concept at all.

I know it might be a stupid question,

There are such things as stupid questions, but I don't think of this as
being one of them.

<snip>

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Walter Roberson]

In article <Ve************ *************** ***@bt.com>,
Richard Heathfield <rj*@see.sig.in validwrote:

>I'm pretty sure Unix thinks of directories as merely a weird kind of file.
For example, IIRC you can fopen them.

That depends on the Unix version. It was traditionally true in
System V unix with the 14 character path components and 2 character inode
numbers, but as filesystems became more advanced and directory files
become more complex, it wasn't uncommon for Unices to prevent users
from fopen'ing directories.
--
Okay, buzzwords only. Two syllables, tops. -- Laurie Anderson

[mensanator]

Richard Heathfield wrote:

Sensei said:

I was having an interesting discussion about the ANSI C and some
``weird inconsistencies '', or at least what at first sight can be seen
as an imbalance. I hope someone can satisfy my curiosity.

The standard provides means to open files associating a /path/ with a
/stream/. The standard does not provide any means to handle
/directories/. There are three streams defined by the standard, stdin
stdout stderr. Am I right?

Almost. The only time the Standard uses the word "path" is in a different
context completely: "Other paths to program termination, such as calling
the abort function, need not close all files properly", which is obviously
not what you are talking about! Otherwise, yes, you are correct.

Now, what is the reason for /not/ defining the directory counterparts
for files (something like fopen, with a directory dopen)?

Not all file systems have the concept of "directory" , and this includes some
prominent systems such as VM/CMS and OS390 (aka MVS). CP/M had no concept
of "directory" either. Nor did MS-DOS 1.0. Undoubtedly there are others,
too.

Yeah, the PDP-11 I used with an RT-11 OS had no subdirectories.
All the files were in one place, had to be unique names and limited
to 8 characters (I think). It was a real PITA.

OTOH, you never had to recurse subdirectories.

>
<snip>

[...] Is the standard going to change?

It's very unlikely.

Are directories treated as normal files?

I'm pretty sure Unix thinks of directories as merely a weird kind of file.
For example, IIRC you can fopen them. Windows sees them as being separate
beasts altogether (and you can't fopen them). And, as I said, some systems
don't have the concept at all.

I know it might be a stupid question,

There are such things as stupid questions, but I don't think of this as
being one of them.

<snip>

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[John Bode]

Richard Heathfield wrote:

Sensei said:

[snip]

>

Now, what is the reason for /not/ defining the directory counterparts
for files (something like fopen, with a directory dopen)?

Not all file systems have the concept of "directory" , and this includes some
prominent systems such as VM/CMS and OS390 (aka MVS). CP/M had no concept
of "directory" either. Nor did MS-DOS 1.0. Undoubtedly there are others,
too.

HP MPE and Encore MPX are two that I worked on personally. IIRC, the
file naming syntax was something like group.account.f ilename, and none
of the three elements could exceed 8 characters.

C is a product of the early '70s and this is one area where it shows.

[pete]

Sensei wrote:

There are three streams defined by the standard, stdin
stdout stderr. Am I right?

stdin, stdout and stderr, are macros
which expand to expressions of type FILE *.
The proper names of the streams are "standard input",
"standard output", and "standard error".
However, the streams are frequemtly refered to by their
associated macros.

--
pete

[Kenneth Brody]

John Bode wrote:

>
Richard Heathfield wrote:

Sensei said:

[...]

Now, what is the reason for /not/ defining the directory counterparts
for files (something like fopen, with a directory dopen)?

Not all file systems have the concept of "directory" , and this includes some
prominent systems such as VM/CMS and OS390 (aka MVS). CP/M had no concept
of "directory" either. Nor did MS-DOS 1.0. Undoubtedly there are others,
too.

HP MPE and Encore MPX are two that I worked on personally. IIRC, the
file naming syntax was something like group.account.f ilename, and none
of the three elements could exceed 8 characters.

C is a product of the early '70s and this is one area where it shows.

On the other hand, why should the C standard care about the layout
of the filesystem on which it's running? Sure, I suppose one could
add some standard library functions (which, I suppose, would fail on
systems without "directorie s" and the like), but why bother? There
is already a POSIX standard which you can stick with if necessary.

Sometimes, O/S-related things don't necessarily belong in the language
specification.

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer .h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th***** ********@gmail. com>

[Kenneth Brody]

pete wrote:

>
Sensei wrote:

There are three streams defined by the standard, stdin
stdout stderr. Am I right?

stdin, stdout and stderr, are macros
which expand to expressions of type FILE *.
The proper names of the streams are "standard input",
"standard output", and "standard error".
However, the streams are frequemtly refered to by their
associated macros.

I don't believe that the standard requires that they be macros. They
simply need to be of type FILE*.

(I'm going by memory here, as I believe someone else quoted C&V about
this in the not-too-distant past.)

That said, all implementations I've bothered looking at were, as I
recall, implemented as macros.

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer .h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th***** ********@gmail. com>

[Sensei]

Thanks to everybody! I can now see some historical reasons for this
reason, I knew there were some :)
--
Sensei <senseiwa@Apple 's mail>

Research (n.): a discovery already published by a chinese guy one month
before you, copying a russian who did it in the 60s.

[forkazoo]

Sensei wrote:

Thanks to everybody! I can now see some historical reasons for this
reason, I knew there were some :)
--
Sensei <senseiwa@Apple 's mail>

Research (n.): a discovery already published by a chinese guy one month
before you, copying a russian who did it in the 60s.

Not only historical reasons, but also forward looking reasons. Many OS
vendors have been rumbling for years about eliminating our concepts of
the file system, and replacing them with a real database. Others have
suggested doing things like file type conversions at the OS level, so
you could conveivably see things like this at some point in the future:
(just examples, future syntax would probably look completely
different!)

fopen("!/SELECT NEWEST FILE WHERE CREATOR='bobsmi th@local' AND
TYPE='imagefile '");

or

fopen("/home/bobsmith/images/sunflower.jpg") ; to open the jpeg file
fopen("/home/bobsmith/images/sunflower.jpg/?convert=PNG"); to have the
system automatically convert the image to PNG, and then open that file.

So, in the first example, there is nothing like a directory. In the
second example, it would be really hard to figure out if sunflower.jpg
is supposed to be treated as a file, or as a directory containing
everything that the system could give you. Some platforms could even
allow http:// addresses right in fopen if they wanted, I think.

So, it would be really handy to have functions for dealing with
directories, but there are potentially so many ways of getting at a
file that if the C standard were to decide on one particular way, it
would probably make it unlikely that anybody would bother to come up
with something better.

At least, that's my personal take on why you will probably never see
directory related functionality in the C standard.