directories

[sid]

Hi
I want to write a C program that can read directories (say list them
as well).
I found out that we could use an API provided by dirent.h header file,
but I am not too keen on using the API. I want to access it directly
without any API. Any help is welcome.
Thank you.

 

[Jens Thoms Toerring]

I want to write a C program that can read directories (say list them
as well).
I found out that we could use an API provided by dirent.h header file,
but I am not too keen on using the API. I want to access it directly
without any API. Any help is welcome.

Since C programs also have to run on machines were directories
don't exist there are no functions in standard C for e.g. lis-
ting the contents of a directory. Instead you have to use some
functions that are supplied by your system. On e. g. POSIX com-
pliant systems these are opendir(), readdir() and closedir().
On others you may have to use other functions.

I don't know what you mean with "I want to access it directly
without any API." Do you want to extract the directory infor-
mation directly from the raw data on the disk? That would be
a rather difficult task and would make your program extremely
system specific (and would work only for the types of file
systems you include support for in your program). If you are
looking for information about this you have to ask in a group
that deals with low level programming on your target system.

Regards, Jens

 

[Erik Trulsson]

Hi
I want to write a C program that can read directories (say list them
as well).
I found out that we could use an API provided by dirent.h header file,
but I am not too keen on using the API. I want to access it directly
without any API. Any help is welcome.
Thank you.

Standard C does not provide any support for reading or otherwise handling
directories.

You will have to use some platform-specific extensions to accomplish that.
Under Unix (with relatives) you can use opendir()/readdir().
Other systems may require other solutions.

 

[Chris Dollin]

Hi
I want to write a C program that can read directories (say list them
as well).
I found out that we could use an API provided by dirent.h header file,
but I am not too keen on using the API. I want to access it directly
without any API.

This is called "asking for trouble". Avoiding an API for doing X
can be like avoiding safety goggles, ignoring RADIATION signs,
or connecting your computer to the mains by stuffing the wires
into the socket holes directly without the inconvenience of a plug.

Sometimes you need to get behind the API. More often, you only /think/
you need to.

--
"Its deductive method was holistic, totalising, /Perdido Street Station/
and inconstant."

Hewlett-Packard Limited registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England

 

[Richard Tobin]

I found out that we could use an API provided by dirent.h header file,
but I am not too keen on using the API. I want to access it directly
without any API. Any help is welcome.

There may not be any way to do so. The operating system may not
provide a method of reading the directory directly. If it does, it
may only do so for certain filesystem types.

Why do you want to do this? What is the real problem you are trying to
solve?

-- Richard

 

[Ben Bacarisse]

Since C programs also have to run on machines were directories
don't exist there are no functions in standard C for e.g. lis-
ting the contents of a directory.

C also has to run on systems without files and on systems without a
"command processor" but it has file operations and the 'system'
function. I don't see a technical reason why they could be provided
as standard. They simply would not do anything if there were no
directories.

 

[jacob navia]

C also has to run on systems without files and on systems without a
"command processor" but it has file operations and the 'system'
function. I don't see a technical reason why they could be provided
as standard. They simply would not do anything if there were no
directories.

This is a typical situation. Here you have TWO choices:

Standardize targeting a high level platform. Platforms that
do not support the feature being standardized just return error
codes.

Standardize targeting the lowest level platform. This way
higher level platform users are remained that C is useful
for only low level platforms and should go to C++.

Easy isn't it?

 

[Ben Bacarisse]

This is a typical situation. Here you have TWO choices:

No, it is not binary choice.

Standardize targeting a high level platform. Platforms that
do not support the feature being standardized just return error
codes.

You have to choose how "high level" you go. If you go too high level
almost all user programs get full of conditional tests for the
features. Too low-level and you miss out on useful functions. The
clever bit would be to pick exactly the right level that is useful for
a large range of applications and can be implemented "almost
everywhere".

Standardize targeting the lowest level platform. This way
higher level platform users are remained that C is useful
for only low level platforms and should go to C++.

Eh? The last time I looked C++ does not have directory operations
either.

Easy isn't it?

I think the choice is quite hard (at least I would not like to have to
make it and the defend it against all comers). In practise, most
people just go with ISO C + POSIX but I come form the world where that
is the norm. I am not sure what is gained by putting more functions
into the *language* standard.

 

[jacob navia]

I think the choice is quite hard (at least I would not like to have to
make it and the defend it against all comers). In practise, most
people just go with ISO C + POSIX but I come form the world where that
is the norm. I am not sure what is gained by putting more functions
into the *language* standard.

Well almost all workstations OSes and many
embedded systems today have a directory structure

Simple abstractions like
opendir etc, as recommended by a simplified version of
POSIX would make programs more portable. At least
they would provide a natural way to do an iteration
trough a directory!

 

[Keith Thompson]

Well almost all workstations OSes and many
embedded systems today have a directory structure

Yes, and most of them support POSIX. I don't think there'd be much
benefit in duplicating POSIX functionality in the C standard.

As for embedded systems, most of them have what the C standard calls
"freestanding implementations", which means they aren't even required
to support <stdio.h>. Presumably the same would apply to any added
directory functions.

A freestanding implementation can as easily support, as an extension,
some subset of POSIX as it can support, as an extension, some subset
of the C standard library.

 

[user923005]

Hi
I want to write a C program that can read directories (say list them
as well).
I found out that we could use an API provided by dirent.h header file,
but I am not too keen on using the API. I want to access it directly
without any API. Any help is welcome.

When you make a function call in C to any library function, you are
calling an API:
http://en.wikipedia.org/wiki/API

By what sort of magic do you expect to collect directory information
without using an API?

P.S.:
http://legacy.imatix.com/html/sfl/

 

[Walter Roberson]

When you make a function call in C to any library function, you are
calling an API:
http://en.wikipedia.org/wiki/API

By what sort of magic do you expect to collect directory information
without using an API?

Original Unix filesystems, open the directory as a regular file and read
and interpret the byte-stream ?? There were convenient
fixed-width entries (14 characters, plus a two-byte inode number).
OS re-writing of entire directory blocks (e.g., compacting out
entries no longer used) was controversial, since doing so destroyed
assumptions that directories could be iterated through from begining
to end.


(As Walter Clinton might once have said: "I have never hacked that API!")

 

[Richard Tobin]

I found out that we could use an API provided by dirent.h header file,
but I am not too keen on using the API. I want to access it directly
without any API. Any help is welcome.

[/QUOTE]

When you make a function call in C to any library function, you are
calling an API:
http://en.wikipedia.org/wiki/API

10/10 for pedantry, 0/10 for English comprehension. Obviously he wants
to avoid using any *directory reading* API.

-- Richard

 

[Keith Thompson]

10/10 for pedantry, 0/10 for English comprehension. Obviously he wants
to avoid using any *directory reading* API.

Yes, he said so. I think the point (with which I agree) is that
that's an unreasonable requirement.

The real question for the OP is: *why* are you "not too keen on using
the API"? What advantage to you foresee from using something other
than the API?

 

[user923005]

Original Unix filesystems, open the directory as a regular file and read
and interpret the byte-stream ?? There were convenient
fixed-width entries (14 characters, plus a two-byte inode number).
OS re-writing of entire directory blocks (e.g., compacting out
entries no longer used) was controversial, since doing so destroyed
assumptions that directories could be iterated through from begining
to end.

From the link that you cut to SFL, we have this directory API that
works on POSIX and Windows:

Directory access functions

Filename: sfldir.h
Package: Standard Function Library (SFL)
Written: 1996/04/02 iMatix SFL project team (e-mail address removed)
Revised: 2000/01/18
Copyright: Copyright (c) 1996-2000 iMatix Corporation
Synopsis

The directory access functions provide a portable interface to the
system's file directory structure. In general these functions are
modelled around the UNIX opendir and readdir functions, but they are
also similar to the DOS interface. These functions can fail on SVr4 if
the <dirent.h> file does not match the C library. Recompile with the
switch -D _USE_BSD_DIRENT and they should work a bit better. Tested
on: MS-DOS (Turbo-C), Windows (MSVC 4.0), UNIX (Linux, IBM AIX,
SunOS). OS/2 port was done by Ewen McNeill (e-mail address removed). DJGPP and
DRDOS LFN by Rob Judd (e-mail address removed). Changes for Win32 by Will
Menninger (e-mail address removed).
List of Functions

* Bool open dir
(DIRST *dir, const char *dir_name);
* Bool read dir
(DIRST *dir);
* Bool close dir
(DIRST *dir);
* char * format dir
(DIRST *dir, Bool full);
* int fix dir
(DIRST *dir);
* int free dir
(DIRST *dir);
* char * resolve path
(const char *path);
* char * locate path
(const char *root, const char *path);
* char * clean path
(const char *path);
* NODE * load dir list
(const char *dir_name, const char *sort);
* void sort dir list
(NODE *filelist, const char *sort);
* FILEINFO * add dir list
(NODE *filelist, const DIRST *dir);
* void free dir list
(NODE *filelist);
* char * get curdir
(void);
* int set curdir
(const char *path);
* Bool file matches
(const char *filename, const char *pattern);
* int make dir
(const char *path);
* int remove dir
(const char *path);
* qbyte dir usage
(const char *path, Bool recurse);
* qbyte dir files
(const char *path, Bool recurse);

 

[user923005]

10/10 for pedantry, 0/10 for English comprehension.  Obviously he wants
to avoid using any *directory reading* API.

If he is totally against using an API, he could #include the SFL C
files.
My point was that the OP *should* be using an API. I thought I was
clear, but apparently not. Sometimes, things that seem so obvious to
me that there is no way I should have to say them out loud come across
as impenetrable to many other people. Not using an API to read a
directory is {while not impossible} commical at best.

IMO-YMMV.

 

[Lew Pitcher]

If he is totally against using an API, he could #include the SFL C
files.

How is "SFL C" different from an API? From your previous post, "SFL C" seems
to include various functions to directly manipulate directories, and that
(to me) makes "SFL C" an Application Program Interface (perhaps not
the /native/ API, though)

If the OP wishes to avoid using a "directory-manipulation API", he might
wish to fopen() the raw devices (if such is possible on his platform), and
fread() his way through the data on the device, decoding data structures in
his own program logic to locate file directories. This will require a large
amount of programming, with "complete familiarity" (as my old job
descriptions used to say) of how the filesystem is structured and stored.

OTOH, if the OP wishes to avoid using /any/ API at all, then I wish him the
best of luck. Since fopen()/fread()/fclose() /are/ APIs, his goal clearly
precludes his use of them (or any other function defined outside of his own
code). He will not only have to process the data on the raw device as
before, he will have to create /his own/ I/O facilities. Big job.

Either way, I wish him the best of luck.

[snip]
--
Lew Pitcher

Master Codewright & JOAT-in-training | Registered Linux User #112576
http://pitcher.digitalfreehold.ca/ | GPG public key available by request
---------- Slackware - Because I know what I'm doing. ------

 

[Lew Pitcher]

NB ==============================================================

How is fopen() not an API?

fopen() is not a "directory-manipulation API". Perhaps you missed the first
sentence in this paragraph? Anyway, see below

NB ==========================================

precludes his use of them (or any other function defined outside of his
own
code). He will not only have to process the data on the raw device as
before, he will have to create /his own/ I/O facilities. Big job.

Either way, I wish him the best of luck.

[snip]
--
Lew Pitcher

Master Codewright & JOAT-in-training | Registered Linux User #112576
http://pitcher.digitalfreehold.ca/ | GPG public key available by
request
---------- Slackware - Because I know what I'm doing.

--
Lew Pitcher

Master Codewright & JOAT-in-training | Registered Linux User #112576
http://pitcher.digitalfreehold.ca/ | GPG public key available by request
---------- Slackware - Because I know what I'm doing. ------