WHY doesn't C know anything about directories?

[David Mathog]

There have been a series of questions about directory operations, all of
which have been answered with "there is no portable way to do this".

This raises the perfectly reasonable question, why, in this day and age,
does the C standard have no abstract and portable method for
dealing with directories? It doesn't seem like a particularly
difficult problem. For instance, this

int show_current_directory(struct DIRSTRUCT *current_directory);

could return status values like these:

VALID_DIRECTORY
success, and the structure is filled in
PLATFORM_HAS_NO_DIRECTORIES
self evident, what you'd see on an embedded controller, for
instance.
CURRENT_DIRECTORY_DOES_NOT_EXIST
like after "cd /newdirectory", when
the directory has not been created yet. Structure
is filled in. Some bit in that structure indicates
that the directory doesn't actually exist.
ERROR
self evident

The organization of DIRSTRUCT could be platform dependent, so
long as key operations (navigation, create directory, delete
directory, compare directory structures [am I in this directory?]) are
fully supported by functions operating on this type.

So, what's the real scoop. Why doesn't the standard support
portable directory operations????

Thanks,

David Mathog

[Ben Pfaff]

David Mathog <ma****@caltech.eduwrites:

This raises the perfectly reasonable question, why, in this day and age,
does the C standard have no abstract and portable method for
dealing with directories?

Probably because there are perfectly good directory APIs supplied
by standards that build upon C, e.g. SUSv3 and its predecessors.
There's no need to integrate these standards into C.
--
Ben Pfaff
http://benpfaff.org

[Chris Hills]

In article <f4**********@naig.caltech.edu>, David Mathog
<ma****@caltech.eduwrites

>There have been a series of questions about directory operations, all
of which have been answered with "there is no portable way to do this".

This raises the perfectly reasonable question, why, in this day and age,
does the C standard have no abstract and portable method for
dealing with directories? It doesn't seem like a particularly
difficult problem.

Because not all file systems are the same.
There are many variants about and already in place.
Any new system would break many of them

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[David Mathog]

Ben Pfaff wrote:

David Mathog <ma****@caltech.eduwrites:

>This raises the perfectly reasonable question, why, in this day and age,
does the C standard have no abstract and portable method for
dealing with directories?

Probably because

(snip)

Actually I was hoping one of the parties who was actually in on the
decision could tell us. We can all guess but I'd like to know what the
actual reasons were.

Thanks,

David Mathog

[Clever Monkey]

David Mathog wrote:

There have been a series of questions about directory operations, all of
which have been answered with "there is no portable way to do this".

This raises the perfectly reasonable question, why, in this day and age,
does the C standard have no abstract and portable method for
dealing with directories? It doesn't seem like a particularly
difficult problem. For instance, this

int show_current_directory(struct DIRSTRUCT *current_directory);

What is a directory? I'm writing a program on a segmented-model
microcontroller that has no host operating system and knows nothing
about things like "files" and "directories".

Various implementations may add functionality that knows how to talk to
directories, but it was decided this has no place in the core, portable
language.

[Ben Pfaff]

David Mathog <ma****@caltech.eduwrites:

Ben Pfaff wrote:

>David Mathog <ma****@caltech.eduwrites:

>>This raises the perfectly reasonable question, why, in this day and age,
does the C standard have no abstract and portable method for
dealing with directories?

Probably because

(snip)

Actually I was hoping one of the parties who was actually in on the
decision could tell us. We can all guess but I'd like to know what the
actual reasons were.

In that case you might consider asking in comp.std.c. That's
where more of the standards committee members hang out.
--
A competent C programmer knows how to write C programs correctly,
a C expert knows enough to argue with Dan Pop, and a C expert
expert knows not to bother.

[Alan Curry]

In article <r5******************@nnrp.ca.mci.com!nnrp1.uunet. ca>,
Clever Monkey <sp******@clevermonkey.org.INVALIDwrote:

>>

What is a directory? I'm writing a program on a segmented-model
microcontroller that has no host operating system and knows nothing
about things like "files" and "directories".

So your case either proves that the standard C library should not have any
file-related functions, or that there would be no harm in adding
directory-related functions since they would have exactly the same status on
your platform as the file-related functions. Which is it?

>
Various implementations may add functionality that knows how to talk to
directories, but it was decided this has no place in the core, portable
language.

So you're lobbying to have stdio removed from standard C too, because what's
not supported by your platform has no place in the core?

--
Alan Curry
pa****@world.std.com

[Richard Heathfield]

David Mathog said:

There have been a series of questions about directory operations, all
of which have been answered with "there is no portable way to do
this".

This raises the perfectly reasonable question, why, in this day and
age, does the C standard have no abstract and portable method for
dealing with directories?

How are you going to deal *portably* with directories on a system that
doesn't have them? Examples include VM/CMS and OS390, both of which are
currently used around the world in the production environments of many
large corporations. These systems /do/ have file organisation methods,
but they ain't directories or anything like.

So, what's the real scoop. Why doesn't the standard support
portable directory operations????

Because the concept itself is not portable.

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

[Mark McIntyre]

On Tue, 05 Jun 2007 08:58:28 -0700, in comp.lang.c , David Mathog
<ma****@caltech.eduwrote:

>There have been a series of questions about directory operations, all of
which have been answered with "there is no portable way to do this".

This raises the perfectly reasonable question, why, in this day and age,
does the C standard have no abstract and portable method for
dealing with directories?

C is designed to be very very portable. As you note, nany platforms on
which C is available have no concept of directories - many have no
concept of disk-based storage at all. So this would all be overhead.

>It doesn't seem like a particularly
difficult problem. For instance,

(snip possible way to provide access to directory functionality)

Yes, that'd be possible. The stdio functions probably work much that
way on a platform with no files.

On the other hand, all platforms that support directories /already/
provide facilities to access them. So C would merely be wrapping
existing functionality in a fairly heavy overcoat. If you've ever used
something like Neuron Data, you'll know that providing true
crossplatform facilities can be very expensive and complicated.

And what is 'in' and 'out' was decided by a committee of users,
developers, and vendors. There was presumably no significant demand
from the community to provide a unified directory layer over the top
of the existing structures which everyone was happy with.

>So, what's the real scoop. Why doesn't the standard support
portable directory operations????

Essentially because a line had to be drawn somewhere.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Alan Curry]

In article <A4******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:

>
How are you going to deal *portably* with directories on a system that
doesn't have them?

The same way you deal with fopen() on a system that doesn't have any files.
By allowing the standardized opendir() to be an always-return-NULL function
on a system that doesn't have anything matching the directory abstraction.

--
Alan Curry
pa****@world.std.com

[Richard Heathfield]

Alan Curry said:

In article <A4******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:

>>
How are you going to deal *portably* with directories on a system that
doesn't have them?

The same way you deal with fopen() on a system that doesn't have any
files. By allowing the standardized opendir() to be an
always-return-NULL function on a system that doesn't have anything
matching the directory abstraction.

I fail to see how this gains us anything, since it basically means that
people will be encouraged to write "standard" C programs for hosted
environments which will nevertheless be non-portable to real, serious,
big iron. The *whole point* of a standard is to prevent this. Yes,
embedded systems have some get-outs such as you describe (e.g. not even
having to /provide/ an fopen, let alone returning a null pointer from
one), but this makes writing portable programs *more* difficult, not
less difficult.

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

[Lew Pitcher]

On Jun 5, 11:58 am, David Mathog <[e-mail]:

There have been a series of questions about directory operations, all of
which have been answered with "there is no portable way to do this".

This raises the perfectly reasonable question, why, in this day and age,
does the C standard have no abstract and portable method for
dealing with directories?

[snip]

Well, you've got a number of answers, most of which I agree with.

I'll add my opinion to the mix, though.

IMHO, the existing definition of the C language already has enough in
it to permit "directory" operations without needing additional
features.

Without violating the semantics of the current C standard, a
hypothetical implementation /could/ provide mechanisms within the
existing stdio definition to permit any sort of directory operations
that you like.

Want to enumerate the files within a directory? This hypothetical
implementation could offer a stream consisting of newline delimited
filenames when a specific filename is read. As in

#include <stdio.h>

{
FILE *directory;

if ((directory = fopen("/some/implementation/defined/path/to/a/
directory/*","r")) != NULL)
{
int byte;

printf("contents of directory:");
while ((byte=fgetc(directory)) != EOF) putc(byte); /* print
file names */
fclose(directory);
}
}

Want to delete a directory?
remove("/some/implementation/defined/path/to/a/directory");

Want to rename a directory
rename("/some/implementation/defined/path/to/a/directory","/some/
other/implementation/defined/path");

Want to change current working directories?
{
FILE *cwd;

if ((cwd = fopen("SYSTEM:current working directory","w") != NULL)
{ fprintf(cwd,"/some/new/path"); fclose(cwd); }

}

And so on.

All you need is an implementation-defined filename string and the
existing standard file functions, and a hypothetical implementation of
a standard C compiler and runtime could offer directory operations /
without violation or extension/ of the existing C standard

Just my two cents worth (1.98 cents US)
--
Lew

[Kenneth Brody]

Alan Curry wrote:

>
In article <A4******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:

How are you going to deal *portably* with directories on a system that
doesn't have them?

The same way you deal with fopen() on a system that doesn't have any files.
By allowing the standardized opendir() to be an always-return-NULL function
on a system that doesn't have anything matching the directory abstraction.

How would you handle the fact that different systems represent
directory trees differently in filenames? One system may have
something like "/hd1/appl/foobar/data.txt" and another one may
have "disk$1:[appl.foobar]data.txt", and perhaps yet another
may have "data.txt:1".

--
+-------------------------+--------------------+-----------------------+
| 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>

[Clever Monkey]

Alan Curry wrote:

In article <r5******************@nnrp.ca.mci.com!nnrp1.uunet. ca>,
Clever Monkey <sp******@clevermonkey.org.INVALIDwrote:

>What is a directory? I'm writing a program on a segmented-model
microcontroller that has no host operating system and knows nothing
about things like "files" and "directories".

So your case either proves that the standard C library should not have any
file-related functions, or that there would be no harm in adding
directory-related functions since they would have exactly the same status on
your platform as the file-related functions. Which is it?

Certainly not. My reason is just /one/ of the reasons for "missing"
directory abstractions. See the discussion else thread. There is more
here than a simply dichotomy.

C has a legacy that assumes that a directory is a file, and that basic,
standard abstractions of "FILE" for most systems is Good Enough.
Removing this legacy would be hard to explain. Adding arbitrary stuff
as the language matured is also hard to explain. A line has to be drawn
somewhere, and I'm not sure that implementing a DIR pointer is near that
line.

Given how useless FILE is on some platforms, what form would an even
more complex DIR expression take?

I'm surprised that anyone finds this surprising. One may as well ask
why there are no modern intrinsic string handling routines in C (and
then be shouted down). And yet, it is one of the first things I have to
implement when building any real application or library.

>Various implementations may add functionality that knows how to talk to
directories, but it was decided this has no place in the core, portable
language.

So you're lobbying to have stdio removed from standard C too, because what's
not supported by your platform has no place in the core?

I'm at a loss to explain how you got to what I said to "lobby".
--
clvrmnky <mailto:sp******@clevermonkey.org>

Direct replies will be blacklisted. Replace "spamtrap" with my name to
contact me directly.

[Clever Monkey]

Kenneth Brody wrote:

Alan Curry wrote:

>In article <A4******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:

>>How are you going to deal *portably* with directories on a system that
doesn't have them?

The same way you deal with fopen() on a system that doesn't have any files.
By allowing the standardized opendir() to be an always-return-NULL function
on a system that doesn't have anything matching the directory abstraction.

How would you handle the fact that different systems represent
directory trees differently in filenames? One system may have
something like "/hd1/appl/foobar/data.txt" and another one may
have "disk$1:[appl.foobar]data.txt", and perhaps yet another
may have "data.txt:1".

Indeed. I advise anyone who thinks this is easy to standardize portably
review the history of the Java File and Streams classes, including the
deprecations.

Let it be noted that Java has eschewed the notion of a "directory",
except as a testable instance of File (not unlike a standard IO FILE on
some platforms).

Sun has done a decent job, but it took them a few releases. The
abstract model they came up with does not always work smoothly on all
platforms, and is not the simplest to implement *especially* if you want
any sort of decent performance.
--
clvrmnky <mailto:sp******@clevermonkey.org>

Direct replies will be blacklisted. Replace "spamtrap" with my name to
contact me directly.

[Clever Monkey]

Clever Monkey wrote:

Kenneth Brody wrote:

>Alan Curry wrote:

>>In article <A4******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:
How are you going to deal *portably* with directories on a system that
doesn't have them?
The same way you deal with fopen() on a system that doesn't have any
files.
By allowing the standardized opendir() to be an always-return-NULL
function
on a system that doesn't have anything matching the directory
abstraction.

How would you handle the fact that different systems represent
directory trees differently in filenames? One system may have
something like "/hd1/appl/foobar/data.txt" and another one may
have "disk$1:[appl.foobar]data.txt", and perhaps yet another
may have "data.txt:1".

Indeed. I advise anyone who thinks this is easy to standardize portably
review the history of the Java File and Streams classes, including the
deprecations.

Let it be noted that Java has eschewed the notion of a "directory",
except as a testable instance of File (not unlike a standard IO FILE on
some platforms).

Sun has done a decent job, but it took them a few releases. The
abstract model they came up with does not always work smoothly on all
platforms, and is not the simplest to implement *especially* if you want
any sort of decent performance.

.... and of course Java can push all sorts of portability into highly
system specific VMs, which handle the conversion of a human readable
pathname through an abstract file into a concrete file or directory.

Quoth the Java 1.4.2 Javadocs: "The conversion of a pathname string to
or from an abstract pathname is inherently system-dependent."

That single sentence represents many, many hours of work for me.
--
clvrmnky <mailto:sp******@clevermonkey.org>

Direct replies will be blacklisted. Replace "spamtrap" with my name to
contact me directly.

[Malcolm McLean]

"David Mathog" <ma****@caltech.eduwrote in message

This raises the perfectly reasonable question, why, in this day and age,
does the C standard have no abstract and portable method for
dealing with directories? It doesn't seem like a particularly
difficult problem.

To implement a portable directory libbrary for PCs would be trivial. On
embedded systems you can just return empty lists.

The snag comes with big multi-user systems. A file you list might disappear
in the nanoseconds between call the function and it returning. Then an
enumeration of files might take ten minutes - some directories on our system
have tens of thousands of files, and that is a relatively small biochemical
database.

Whilst it probbaly wouldn't have been impossible to come up with something,
the difficulties were enough to reject the idea.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Christopher Benson-Manica]

Lew Pitcher <lp******@teksavvy.comwrote:

Without violating the semantics of the current C standard, a
hypothetical implementation /could/ provide mechanisms within the
existing stdio definition to permit any sort of directory operations
that you like.

While I imagine that the hypothetical implementation you've described
would be conforming, I'm not sure the situation qualifies as a data
point against the idea that the C standard should not specify such
behavior for implementations that choose to handle directory
operations. If a program could be guaranteed that *if* the
implementation provided directory services, they would be provided in
a standard way, a number of new functional possibilities could be
available to implementors.

--
C. Benson Manica | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com | don't, I need to know. Flames welcome.

[Mark McIntyre]

On Tue, 05 Jun 2007 09:53:31 -0700, in comp.lang.c , David Mathog
<ma****@caltech.eduwrote:

>Ben Pfaff wrote:

>David Mathog <ma****@caltech.eduwrites:

>>This raises the perfectly reasonable question, why, in this day and age,
does the C standard have no abstract and portable method for
dealing with directories?

Probably because

(snip)

Actually I was hoping one of the parties who was actually in on the
decision could tell us. We can all guess but I'd like to know what the
actual reasons were.

Unless someone on the committee corrects him, you may assume that
Ben's answer is not a random guess.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Christopher Benson-Manica]

Richard Heathfield <rj*@see.sig.invalidwrote:

I fail to see how this gains us anything, since it basically means that
people will be encouraged to write "standard" C programs for hosted
environments which will nevertheless be non-portable to real, serious,
big iron.

I don't know that the danger would be any more significant than any
number of other non-portable and dangerous assumptions that an
incautious implementor might make. It seems to me to fit in the
"dangerous if misused" category.

--
C. Benson Manica | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com | don't, I need to know. Flames welcome.

[Mark McIntyre]

On Tue, 5 Jun 2007 17:50:40 +0000 (UTC), in comp.lang.c ,
pa****@TheWorld.com (Alan Curry) wrote:

>In article <r5******************@nnrp.ca.mci.com!nnrp1.uunet. ca>,
Clever Monkey <sp******@clevermonkey.org.INVALIDwrote:

>>>

What is a directory? I'm writing a program on a segmented-model
microcontroller that has no host operating system and knows nothing
about things like "files" and "directories".

So your case either proves that the standard C library should not have any
file-related functions, or that there would be no harm in adding
directory-related functions since they would have exactly the same status on
your platform as the file-related functions. Which is it?

Neither. IMHO it proves only that the ISO committee felt that files
were commonplace enough, and yet sufficiently in requirement of
standardisation, that adding support via streams was useful. Whereas
directories were neither sufficiently supported, not sufficiently in
need of a common API.

>>Various implementations may add functionality that knows how to talk to
directories, but it was decided this has no place in the core, portable
language.

So you're lobbying to have stdio removed from standard C too, because what's
not supported by your platform has no place in the core?

Presumably you have a reason for making that statement up, but its not
clear what it is.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Tor Rustad]

Richard Heathfield wrote:

David Mathog said:

>There have been a series of questions about directory operations, all
of which have been answered with "there is no portable way to do
this".

This raises the perfectly reasonable question, why, in this day and
age, does the C standard have no abstract and portable method for
dealing with directories?

How are you going to deal *portably* with directories on a system that
doesn't have them? Examples include VM/CMS and OS390, both of which are
currently used around the world in the production environments of many
large corporations.

To that list, I can add *HP NonStopKernel*, I guess the installation at
AOL uses the Unix like interface, but many still run under Guardian,
which means no directories.

NSK is used all over world, for critical systems:

http://h20223.www2.hp.com/NonStopCom...0-0-0-121.html

Guess what, NSK has a C compiler. :)

--
Tor <torust [at] online [dot] no>

[Keith Thompson]

pa****@TheWorld.com (Alan Curry) writes:

In article <A4******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:

>>
How are you going to deal *portably* with directories on a system that
doesn't have them?

The same way you deal with fopen() on a system that doesn't have any files.
By allowing the standardized opendir() to be an always-return-NULL function
on a system that doesn't have anything matching the directory abstraction.

Systems that don't have files are typically embedded systems, and
typically have freestanding C implementations (as opposed to hosted
implementations). A conforming freestanding implementation needn't
support most of the standard headers at all. In other words, the
typical way to handle fopen() for systems that don't have files is not
to provide it at all, not to have it always return NULL.

It turns out to be a lot easier to define a portable file interface
than to define a portable directory interface. For example, you'd
need to define a way to construct file names from directory names. On
Unix-like systems, you can join the directory path elements together
with '/' characters. On VMS the syntax is much more complex
("SYS$FOO::[DIR1.DIR2.DIR3]FILE.TXT", or something like that). And,
as RH pointed out, some mainframe systems support files, but don't
support directories in any meaningful sense.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[user923005]

On Jun 5, 8:58 am, David Mathog <[e-mail]:

There have been a series of questions about directory operations, all of
which have been answered with "there is no portable way to do this".

This raises the perfectly reasonable question, why, in this day and age,
does the C standard have no abstract and portable method for
dealing with directories? It doesn't seem like a particularly
difficult problem. For instance, this

int show_current_directory(struct DIRSTRUCT *current_directory);

could return status values like these:

VALID_DIRECTORY
success, and the structure is filled in
PLATFORM_HAS_NO_DIRECTORIES
self evident, what you'd see on an embedded controller, for
instance.
CURRENT_DIRECTORY_DOES_NOT_EXIST
like after "cd /newdirectory", when
the directory has not been created yet. Structure
is filled in. Some bit in that structure indicates
that the directory doesn't actually exist.
ERROR
self evident

The organization of DIRSTRUCT could be platform dependent, so
long as key operations (navigation, create directory, delete
directory, compare directory structures [am I in this directory?]) are
fully supported by functions operating on this type.

So, what's the real scoop. Why doesn't the standard support
portable directory operations????

This thingy has a directory abstraction, and is useful for C projects:
http://legacy.imatix.com/html/sfl/

For C++, I prefer this:
http://www.cs.wustl.edu/~schmidt/ACE.html

When you code to one of those standard APIs, your code does not have
to change from system to system.

So why not just fold stuff like the above into the C and C++
standards?

While we could ignore directory services for things like toaster ICs
and other embedded systems, there is still a problem.
The SFL works for POSIX and Windows type systems. No soap on IBM
Mainframes running MVS or VSE and many other systems.
Same for ACE. So it only works on a subset of hosted systems. The
whole point of a nationwide or worldwide standard is that it gives you
a guarantee of how things are supposed to work. But since we can't
make it work that way, we would have to invent a new fork in the
standard:
Hosted, hosted pathless, non-hosted. A bad precedent I think. So why
not just use an existing toolkit that will do what you want to do in
the environment you need to do it in? (After all, you don't usually
need to navigate folders on z/OS except on hosted subsystem operating
systems).

[SM Ryan]

David Mathog <ma****@caltech.eduwrote:

# So, what's the real scoop. Why doesn't the standard support
# portable directory operations????

Inertia.

--
SM Ryan http://www.rawbw.com/~wyrmwif/
Leave it to the Catholics to destroy existence.

[Dik T. Winter]

In article <f4*********@chessie.cirr.comChristopher Benson-Manica <at***@ukato.freeshell.orgwrites:
....

If a program could be guaranteed that *if* the
implementation provided directory services, they would be provided in
a standard way, a number of new functional possibilities could be
available to implementors.

But it remains highly non-portable. Even from stdio, fopen is not
really portable. The only really portable parts of stdion are concerned
with stdin, stdout and stderr. Consider:
fopen("c:\\file", "w");
which works perfectly on the system I am now using, but probably will
not do what the writer of the code intended (it will create the file
named "c:\file" in the current directory). And will work only on some
other system that I am using when there is a directory named "c" in the
current directory.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, [phone]
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[Keith Thompson]

"Dik T. Winter" <Di********@cwi.nlwrites:

In article <f4*********@chessie.cirr.comChristopher Benson-Manica
<at***@ukato.freeshell.orgwrites:
...

If a program could be guaranteed that *if* the
implementation provided directory services, they would be provided in
a standard way, a number of new functional possibilities could be
available to implementors.

But it remains highly non-portable. Even from stdio, fopen is not
really portable. The only really portable parts of stdion are concerned
with stdin, stdout and stderr. Consider:
fopen("c:\\file", "w");
which works perfectly on the system I am now using, but probably will
not do what the writer of the code intended (it will create the file
named "c:\file" in the current directory). And will work only on some
other system that I am using when there is a directory named "c" in the
current directory.

Sure, but hard-wiring a file name into a program is bound to be
non-portable.

As far as stdio is concerned, a file name is an arbitrary string to be
passed to fopen(). Programs usually obtain file names from
command-line arguments or by reading other files.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Christopher Benson-Manica]

Keith Thompson <ks***@mib.orgwrote:

Sure, but hard-wiring a file name into a program is bound to be
non-portable.

I think it's worth making the distinction between absolute and
relative paths; the latter is more likely to be generally useful than
the former. The primary difficulty with supporting relative paths
would seem to be the identity of the path delimiter.

--
C. Benson Manica | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com | don't, I need to know. Flames welcome.

[Keith Thompson]

Christopher Benson-Manica <at***@otaku.freeshell.orgwrites:

Keith Thompson <ks***@mib.orgwrote:

>Sure, but hard-wiring a file name into a program is bound to be
non-portable.

I think it's worth making the distinction between absolute and
relative paths; the latter is more likely to be generally useful than
the former. The primary difficulty with supporting relative paths
would seem to be the identity of the path delimiter.

And the difficulty with relative paths is that the syntax of a file
name varies from one system to another. Some systems may place an
upper bound on the length of a file name, or disallow certain
characters, or ignore distinctions between upper and lower case, or
require exactly one '.' character, and so forth.

The C standard's requirements for header names (C99 6.10.2p5):

The implementation shall provide unique mappings for sequences
consisting of one or more letters or digits (as defined in 5.2.1)
followed by a period (.) and a single letter. The first character
shall be a letter. The implementation may ignore the distinctions
of alphabetical case and restrict the mapping to eight significant
characters before the period.

are intended to be achievable on all systems -- but even then the
specified strings need only be mapped to actual file names (they
needn't actually be file names).

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Christopher Benson-Manica]

Keith Thompson <ks***@mib.orgwrote:

And the difficulty with relative paths is that the syntax of a file
name varies from one system to another.

I do suppose that's rather a thornier issue for an implementation to
resolve.

The C standard's requirements for header names (C99 6.10.2p5):
(snip)

In an only tenuously related question, does this paragraph mean that
header includes such as <sys/unistd.hare disallowed, or merely that
the implementation need not provide a "unique mapping" to the header
so identified?

--
C. Benson Manica | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com | don't, I need to know. Flames welcome.

[David Mathog]

Kenneth Brody wrote:

How would you handle the fact that different systems represent
directory trees differently in filenames? One system may have
something like "/hd1/appl/foobar/data.txt" and another one may
have "disk$1:[appl.foobar]data.txt", and perhaps yet another
may have "data.txt:1".

That was the whole point of having an abstract platform specific
struct contain the directory specification and defining
functions to operate on this structure.

The primary purpose of directories, and also some of the file
organization methods on systems without directories, is just that: file
organization. Directories allow a person (and program) to place and
later find files. What I was thinking of was something more or less
like this pseudocode:

struct DIRSTRUCT *adirstruct=NULL;
char **list;
char buffer[SIZEBUFFER];
int status;

/* Handle platforms without directory support */
status = directory_support();
if(!status)exit(EXIT_FAILURE);

adirstruct = directory_create_dirstruct();
/*fill it with current directory info*/
status=directory_set_current(&adirstruct);
/*list upward path(s), number found returned in status */
status=directory_navigable(adirstruct,&list,UP);
if(status==1){ /* unix, vms, and other single up organizations */
status=directory_navigate(&adirstruct,0,UP);
}
else if(status>0)
/* insert code to pick one super directory from list as index J */
status=directory_navigate(&adirstruct,J,UP);
}
else {
/* handle no such concept as UP on platform or other error */
}
/*list downward path(s). [not shown here, ACROSS] */
status=directory_navigable(adirstruct,&list,DOWN);
/* insert code to pick one subdirectory from list as index J */
status=directory_navigate(&adirstruct,J,DOWN);
/* chdir() equivalent */
status=directory_change(adirstruct);
status=directory_make_fullpath(adirstruct,buffer,S IZEBUFFER,filename);
/* or after the directory_change, this equivalent
status=directory_make_fullpath(NULL,buffer,SIZEBUF FER,filename);
*/
/* check the status (maybe buffer was too small) NOT SHOWN */
status=fopen(buffer,"w");
/* ... other code, list files in directory */
status=directory_listfiles(adirstruct,&list);

/* create a new directory specification, then create it */
status = directory_new(&adirstruct,DOWN,"newsubdir");
status = directory_create(adirstruct);

And so forth.

The point being that the string syntax used for a directory
specification is never explicitly accessed within the code.
When we need to generate one for use in fopen (for instance),
we use the directory_makepath function to construct something
platform specific, without the programmer seeing, knowing, or
caring about the details.

One could argue that a similar set of functions should also exist for
file name manipulation, so that filename syntax variations could
be similarly abstracted.

Regards,

David Mathog

[user923005]

Directory structures are antiquated loads of crap.

We should put everything into a database (including making the file
system be a database).

For file systems, a network model or hierarchy is probably better than
a relational model.

At any rate, the C language itself is the wrong place to reform
things.

IMO-YMMV.

[Mark McIntyre]

On Wed, 06 Jun 2007 11:14:30 -0700, in comp.lang.c , user923005
<dc*****@connx.comwrote:

>Directory structures are antiquated loads of crap.

We should put everything into a database (including making the file
system be a database).

You've been reading
http://en.wikipedia.org/wiki/WinFS
.....
:-)
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[user923005]

On Jun 6, 3:08 pm, Mark McIntyre <[e-mail]:

On Wed, 06 Jun 2007 11:14:30 -0700, in comp.lang.c , user923005

<[e-mail]:

Directory structures are antiquated loads of crap.

We should put everything into a database (including making the file
system be a database).

You've been readinghttp://en.wikipedia.org/wiki/WinFS
....
:-)

The AS/400 has a database for a file system. The idea is very old.

[Rob Morris]

David Mathog wrote:

There have been a series of questions about directory operations, all of
which have been answered with "there is no portable way to do this".

I suspect the reasons are historical, due to the 'standard I/O' library
predating standard C by some years. As far as I can tell (these events
happening some years before my birth) stdio was developed really quite
early on, providing convenience and portability over and above the UNIX
syscalls.

Ah, here we are, from: http://cm.bell-labs.com/cm/cs/who/dmr/chist.html -
"Also during this period, the compiler was retargeted to other nearby
machines, particularly the Honeywell 635 and IBM 360/370; because the
language could not live in isolation, the prototypes for the modern
libraries were developed. In particular, Lesk wrote a `portable I/O
package' [Lesk 72] that was later reworked to become the C `standard
I/O' routines."

So, further to other answers here, the historical reasons might
specifically be due to the capabilities of the first few systems C was
ported to.
--
Rob Morris: arr emm four four five (at) cam dot ac dot uk

[Richard Bos]

Mark McIntyre <ma**********@spamcop.netwrote:

On Wed, 06 Jun 2007 11:14:30 -0700, in comp.lang.c , user923005
<dc*****@connx.comwrote:

Directory structures are antiquated loads of crap.

We should put everything into a database (including making the file
system be a database).

*Brrrr*

You've been reading
http://en.wikipedia.org/wiki/WinFS

*Brrrrrrrrrrrrr*

Sends my back a-creeping, that does.

But at least it does illustrate why putting directory support into C is
not as simple as it sounds at first.

Richard

[Mark McIntyre]

On Wed, 06 Jun 2007 15:54:18 -0700, in comp.lang.c , user923005
<dc*****@connx.comwrote:

>On Jun 6, 3:08 pm, Mark McIntyre <[e-mail]:

>On Wed, 06 Jun 2007 11:14:30 -0700, in comp.lang.c , user923005

<[e-mail]:

>Directory structures are antiquated loads of crap.

>We should put everything into a database (including making the file
system be a database).

You've been readinghttp://en.wikipedia.org/wiki/WinFS
....
:-)

The AS/400 has a database for a file system. The idea is very old.

I didn't say that the authors of WinFS had an /original/ thought.
(obviously....)
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[David Mathog]

user923005 wrote:

Directory structures are antiquated loads of crap.

We should put everything into a database (including making the file
system be a database).

A. Every computer I work with (locally numbering into the hundreds)
has a directory structure. It would be nice if the language supported
these machines.

B. If there is no way to navigate the database (for instance, no way
to recover a list of the keys it accepts) then

directory_support()

would return false, as it would on an embedded controller.

C. How many keys do these proposed database filing systems require?
The proposed navigation calls already support UP, ACROSS, and DOWN
navigation directions. That should be sufficient to navigate within
a database so long as a list of valid keys can be retrieved and
the number of keys needed to index a file location is finite.

Example, if a group of files is indexed by:

PRIMARY=R_AND_D (division)
SECONDARY=OPTOELECTRONICS (section)
TERTIARY=FLEXIBLE_DISPLAYS (subsection)
QUATERNARY=ORGANIC_LED (sub-subsection)

the navigation functions should work fine, so long as one can
first retrieve all the primary keys, and then for one primary key,
all secondaries, for that primary and secondary all tertiary, and for
that primary, secondary, and tertiary all quaternary.

If one CANNOT retrieve the database index keys how the heck would
one ever locate a file by any sort of search criteria?

Regards,

David Mathog

[Dave Vandervies]

In article <f4**********@naig.caltech.edu>,
David Mathog <ma****@caltech.eduwrote:

>user923005 wrote:

>Directory structures are antiquated loads of crap.

We should put everything into a database (including making the file
system be a database).

A. Every computer I work with (locally numbering into the hundreds)
has a directory structure.

And every computer in the world is a VAX^WSun^WWintel^Wx64.

Therefore, if a VAX^WSun^WWintel^Wx64 can do it, it should be in every
programming langauge in the world.
dave

--
Dave Vandervies dj******@csclub.uwaterloo.ca
As an end-user, I don't care which process is used. ... You could
use wet cardboard, if it worked.
--Kai Harrekilde-Petersen in comp.arch

[Bart van Ingen Schenau]

Christopher Benson-Manica wrote:

Keith Thompson <ks***@mib.orgwrote:

>The C standard's requirements for header names (C99 6.10.2p5):
(snip)

In an only tenuously related question, does this paragraph mean that
header includes such as <sys/unistd.hare disallowed, or merely that
the implementation need not provide a "unique mapping" to the header
so identified?

The paragraph does not state that characters other than letters and
digits are disallowed.
Therefor, an implementation does not have to diagnose a #include
directive of
#include <sys/unistd.h>
but it also does not have to do anything meaningful with it.
Technically, such a directive results in UB, but most implementations
will try to do something sensible (like asking the OS if something by
such a name can be located).

Bart v Ingen Schenau
--
a.c.l.l.c-c++ FAQ: http://www.comeaucomputing.com/learn/faq
c.l.c FAQ: http://www.eskimo.com/~scs/C-faq/top.html
c.l.c++ FAQ: http://www.parashift.com/c++-faq-lite/

[Keith Thompson]

David Mathog <ma****@caltech.eduwrites:

user923005 wrote:

>Directory structures are antiquated loads of crap.
We should put everything into a database (including making the file
system be a database).

A. Every computer I work with (locally numbering into the hundreds)
has a directory structure. It would be nice if the language supported
these machines.

[...]

Yes, it would be nice, but it's not very practical. There are enough
differences between how directories are implemented on different
systems that providing a portable interface is very difficult. Note
that, in the grand scheme of things, Unix and Windows are actually
very similar; if they were the only operating systems in existence, a
"portable" directory interface wouldn't be difficult.

Every operating system that supports directories provides a
system-specific interface to work with directories. A hypothetical
portable interface would inevitably leave out some of the
functionality of the system-specific interface, and a lot of
programmers would just use the system-specific interface even if a
portable interface existed.

Programs that deal with directories tend to be system-specific anyway.
This is to some extent a chicken-and-egg problem, but solving it would
be difficult.

I'm not *necessarily* saying that a standard directory interface is
impossible, but there are a lot of obstacles that many programmers
might not be aware of. David Tribble has proposed such an interface;
see <http://david.tribble.com/text/c0xdir.html>. (I haven't taken a
very close look at it myself.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[David Mathog]

Dave Vandervies wrote:

In article <f4**********@naig.caltech.edu>,
David Mathog <ma****@caltech.eduwrote:

>user923005 wrote:

>>Directory structures are antiquated loads of crap.

We should put everything into a database (including making the file
system be a database).

A. Every computer I work with (locally numbering into the hundreds)
has a directory structure.

And every computer in the world is a VAX^WSun^WWintel^Wx64.

Therefore, if a VAX^WSun^WWintel^Wx64 can do it, it should be in every
programming langauge in the world.

You left off DOS, Mac, and BeOS ;-).

In short, yes, I think that it's daft that C supports fopen() without
also providing a portable way to navigate to the file other
than by creating a path string, which we all know not to be in the least
bit portable. And as I've said a several times already, it's trivial to
provide a test function so that a program can determine at run time
if directory operations are supported. Which I think is still pretty
much a red herring since the overlap between embedded controller
software and the sorts of programs which would benefit from portable
directory navigation is pretty close to the null set.

On the flip side, because there is no way to do this, useful software
that does end up being ported often needs a lot of rewriting to work
around the platform specific directory name and file name conventions,
and also the directory navigation and listing methods, which often are
found scattered around in various parts of the code.

Regards,

David Mathog

[Mark McIntyre]

On Thu, 07 Jun 2007 08:30:41 -0700, in comp.lang.c , David Mathog
<ma****@caltech.eduwrote:

>user923005 wrote:

>Directory structures are antiquated loads of crap.

We should put everything into a database (including making the file
system be a database).

A. Every computer I work with (locally numbering into the hundreds)
has a directory structure.

And a lot of the ones I work with don't.

It would be nice if the language supported
these machines.

No need, since platform-specific extensions do it very well.

>C. How many keys do these proposed database filing systems require?
The proposed navigation calls already support UP, ACROSS, and DOWN
navigation directions. That should be sufficient to navigate within
a database so long as a list of valid keys can be retrieved and
the number of keys needed to index a file location is finite

I don't think you understand how a database filesystem works. Consider
an ordinary RDBMS. A row isn't 'down' from a table, and a row in a
different table isn't 'across'. if you select * from table where
filetype=bla and filedescription like gibble you don't get some sort
of hierarchical tree returned.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Eric Sosman]

David Mathog wrote On 06/07/07 17:01,:

Dave Vandervies wrote:

>>In article <f4**********@naig.caltech.edu>,
David Mathog <ma****@caltech.eduwrote:

>>>user923005 wrote:

Directory structures are antiquated loads of crap.

We should put everything into a database (including making the file
system be a database).

A. Every computer I work with (locally numbering into the hundreds)
has a directory structure.

And every computer in the world is a VAX^WSun^WWintel^Wx64.

Therefore, if a VAX^WSun^WWintel^Wx64 can do it, it should be in every
programming langauge in the world.

You left off DOS, Mac, and BeOS ;-).

In short, yes, I think that it's daft that C supports fopen() without
also providing a portable way to navigate to the file other
than by creating a path string, which we all know not to be in the least
bit portable. And as I've said a several times already, it's trivial to
provide a test function so that a program can determine at run time
if directory operations are supported. Which I think is still pretty
much a red herring since the overlap between embedded controller
software and the sorts of programs which would benefit from portable
directory navigation is pretty close to the null set.

On the flip side, because there is no way to do this, useful software
that does end up being ported often needs a lot of rewriting to work
around the platform specific directory name and file name conventions,
and also the directory navigation and listing methods, which often are
found scattered around in various parts of the code.

In my own experience, "a lot" of rewriting has not
been necessary. If your experience is otherwise, that
might be taken as evidence that the notion of directory
has too many system-specific quirks to be suitable for
standardization ...

--
Er*********@sun.com

[David Mathog]

Mark McIntyre wrote:

On Thu, 07 Jun 2007 08:30:41 -0700, in comp.lang.c , David Mathog
<ma****@caltech.eduwrote:

>It would be nice if the language supported
these machines.

No need, since platform-specific extensions do it very well.

There is a need because it's a PITA to port those platform specific
extensions to another set of platform specific extensions.

>

>C. How many keys do these proposed database filing systems require?
The proposed navigation calls already support UP, ACROSS, and DOWN
navigation directions. That should be sufficient to navigate within
a database so long as a list of valid keys can be retrieved and
the number of keys needed to index a file location is finite

I don't think you understand how a database filesystem works. Consider
an ordinary RDBMS. A row isn't 'down' from a table, and a row in a
different table isn't 'across'. if you select * from table where
filetype=bla and filedescription like gibble you don't get some sort
of hierarchical tree returned.

UP ACROSS and DOWN define navigation on a grid on a 2D surface, which
may or may not have a tree based file system mapped onto it. If a
database can be mapped so that every file it contains lies on
that 2D surface then UP ACROSS and DOWN should be sufficient to navigate
to any of those files. (Not necessarily trivially to any SET of those
files, as could be done with SQL select statements.) Also the
navigation path to each cell, and especially from cell to cell, may not
be unique, but that's true now on Unix directory trees with links
between directories in place.

Another way to think of it with respect to a database
method would be "Less Restrictive", "As Restrictive", "More
Restrictive". Let's ignore the middle one for a minute and work the
example you cited. Admittedly it is a bit counter
intuitive if you're thinking in terms of SQL select statements.

In your example we need to get to all files "in":
some table, filetype=bla, filedescription=gibble.

Start at the database "TOP" (nothing selected)

Navigate DOWN: Lists all tables, from list select a table.
Navigate DOWN: List all columns in table, from list select "fileteype".
Navigate DOWN: List all values in column, from list select "bla".

(if we directory list at this point we get all files for which the
database has filetype=bla.)

The next step is where it becomes counter intuitive. To further
restrict the specification ("DOWN") after one column has been
set requires selecting another column and a key value in it, like this:

Navigate DOWN: List all Columns in table ([OTHER than the one(s)
already selected] ie, further restrict list),
from list select "filedescription".
Navigate DOWN: List all values in column, from list select a
value like "gibble".

List directory: all files for filetype=bla, filedescription=gibble.

UP is even less familiar since it is multivalued.

Navigate UP: lists all less restricted paths, which in this case are:
1. column=filetype(value=bla),column=filedescription
2. column=filetype,column=filedescription(value=gibbl e)

Admittedly this is all AND logic, but it should be sufficient to
find any file stored in the database system, or to place a new
file in the system. It cannot do SETS of files with as much
flexibility as a SQL select statement, but then, none of the native
directory tools I'm aware of are designed for operating on sets of
directories.

The biggest problem I see is that if files in a column were ONLY
organized by numeric indices (for instance a collection number) the list
that came back would be both humongous and essentially meaningless, so
that selecting the next value would be next to impossible. This is
exactly analogous though to creating a zillion subdirectories
with equally meaningless names. Unfortunately an organization
I've encountered a few times.

My point still being, that with C modified this way the program
just sees standard function calls for navigating UP and DOWN and
lists of results, and C never exposes the underlying database or
directory organization. This would allow the same program to
run unchanged on an OS with a tree file system or a database
file system. That would, I think, be a good thing.

Regards,

David Mathog

[Chris Torek]

In article <f4**********@naig.caltech.edu>
David Mathog <ma****@caltech.eduwrote:
[method snipped; leaving just this part in:]

>... should be sufficient to
find any file stored in the database system, or to place a new
file in the system. It cannot do SETS of files with as much
flexibility as a SQL select statement, but then, none of the native
directory tools I'm aware of are designed for operating on sets of
directories.

[more snippage]

>My point still being, that with C modified this way the program
just sees standard function calls for navigating UP and DOWN and
lists of results, and C never exposes the underlying database or
directory organization. This would allow the same program to
run unchanged on an OS with a tree file system or a database
file system. That would, I think, be a good thing.

It might. I suspect, however, that people would end up not using
it, in part because (as you note above) it may be sufficient for
some purposes, but it will not capture the "true nature" of the
underlying OS.

In general, it seems that when people want to operate on directories,
they want to do many (or most or even all) of the things that the
underlying OS does with them. A "subset" interface is, by definition,
not good enough; and a complete one is, by definition, not portable
enough. (They almost always *start* with something that can be
done with a simple "enumerate all files that are members of given
directory" type interface; it just turns out that, once that works,
they suddenly care about whether the file is the latest version or
not, on VMS; or whether it is marked "has system attribute", on
DOS; and so on.)

There do seem to be some exceptions, and those may be common
enough to warrant some sort of "directory access library". But
that is really a topic for comp.std.c, rather than comp.lang.c.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Walter Roberson]

In article <f4**********@naig.caltech.edu>,
David Mathog <ma****@caltech.eduwrote:

>UP ACROSS and DOWN define navigation on a grid on a 2D surface, which
may or may not have a tree based file system mapped onto it.

>Another way to think of it with respect to a database
method would be "Less Restrictive", "As Restrictive", "More
Restrictive".

Since the invention of symbolic links, unix filesystems have not
been tree-based, just approximately tree based. It sounds to me
as if there would be difficulty in translating the unix semantics
that the unix .. ("UP", "Less Restrictive") does not refer to
a fixed location.

NFS mounts also sound tricky to handle, especially cross-mounts
and automounts . Once you have those semantics built in, you also
have to worry about SANs (Storage Area Networks) (which system is
the owner of this shared file?) and about DMF (Data Migration
Facility), which might have multiple levels of storage with files
(and even file -names-) brought back from "near-line" storage at
need. It seems to me that the "reselect and do a fileset AND" semantics
you suggest require that all the names be present at the same time.

There a Microsoft Windows NTFS facility whose name I do not recall at
the moment, partly related to Alternate Data Streams (ADS), which
allowed a directory entry to be a program which interprets the
rest of the path, sort of an API for device driver- like objects.
I'm not sure how that would fit in with your scheme.
Is the facility you propose practical for removable media? Floppies
might be pretty moribund now, but there are USB Keychains, CDs and DVDs,
camera storage, iPods -- pretty high volumes of removable storage,
and which people have come to expect will be trivial to plug in and
have "just work". Would the Database type approach be efficient enough
at rebuilding the file information -quickly- when activating the
removable media, and at removing the information -quickly- when
deactivating the removable media?
--
"No one has the right to destroy another person's belief by
demanding empirical evidence." -- Ann Landers

[Ian Collins]

David Mathog wrote:

There have been a series of questions about directory operations, all of
which have been answered with "there is no portable way to do this".

More of an aside, but you might be interested in the design decisions
behind the proposed C++ filesystem library:

http://www.boost.org/libs/filesystem...al.html#Design

--
Ian Collins.

[Richard Bos]

David Mathog <ma****@caltech.eduwrote:

user923005 wrote:

Directory structures are antiquated loads of crap.

We should put everything into a database (including making the file
system be a database).

A. Every computer I work with (locally numbering into the hundreds)
has a directory structure. It would be nice if the language supported
these machines.

Every computer I work with has a graphics screen. It would be nice if
the language supported these machines. But it doesn't, and there are
very good reasons for that.

B. If there is no way to navigate the database (for instance, no way
to recover a list of the keys it accepts) then

directory_support()

would return false, as it would on an embedded controller.

The question is not of _whether_ the file system is navigable, the
question is _how_. This is not as easy as it sounds at first. Oh, it's
all very well if you only assume Windows and Unix and blithely disregard
such matters as softlinks and devices-as-files, but such a simplified
approach would never work for an ISO Standard.

Files themselves could be included in the Standard because one can
whittle down working with them to a few very portable operations. Open
and close, create and remove, read and write, get, restore and seek
position. And even those have been curtailed to an extent that
invariably trips up all-the-world's-a-desktop-toy programmers: not only
is there no file size function, but you can't even reliably go to the
end of a file and ask for a position in bytes. And this is not, as some
would think, for no better reason than to pester Winblows programmers;
it is because that simply cannot be done on some systems, but those
systems have files that are powerful enough to make giving them the rest
of the file functions worthwhile.
With directories, however, matters are a little more complicated. Even
on systems where you have directories and you can navigate them, there
is no simple way to specify _how_ to navigate them completely and
reliably that works on all systems. If you think that "go to top of
directory tree; list all files; find first sub-directory; recurse; find
next subdirectory; re-recurse" suffices and will do the job on all
systems out there, you simply haven't had much experience of many OSes.
Hell, you probably haven't even considered how you handle Windows drive
letters...

Richard

[Flash Gordon]

Richard Bos wrote, On 08/06/07 08:31:

<snip>

With directories, however, matters are a little more complicated. Even
on systems where you have directories and you can navigate them, there
is no simple way to specify _how_ to navigate them completely and
reliably that works on all systems. If you think that "go to top of
directory tree; list all files; find first sub-directory; recurse; find
next subdirectory; re-recurse" suffices and will do the job on all
systems out there, you simply haven't had much experience of many OSes.
Hell, you probably haven't even considered how you handle Windows drive
letters...

A psuedo-directory one level up that has the drives as simple letters...

I admit I don't know enough about things like database file systems, but
could one not do something very simple like:

int setdir(const char *dir);
Where interpretation of the string is implementation defined, so for a
database filesystem it would be a database query and a unix/dos/windows
filesystem it would be a patch as you would use for chdir.

Then add:
int resetdirpos(void);
To initialise your "directory pointer" to the first file in the "directory"
int readdir(char *name);
To read a name from the directory moving the "directory pointer" on to
the next directory.

Oh, and a function:
int currdir(char *dir);
Where as with setdir the string put in to dir is implementation defined.

It would be enough for me (I could do my own"file globbing" as I read
through the directory. It might not be enough for others (a directory
name of ".." might mean go up on Unix, but not on VMS), but I *think*
that by leaving the strings up to the implementation to define (taking a
page out of how fopen was defined) it allows it to be of *some* use on
any system with multiple files and a way of selecting a subset of all
the files on the system.
--
Flash Gordon