By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,694 Members | 2,121 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,694 IT Pros & Developers. It's quick & easy.

Program to retrieve all filenames in drive

P: n/a
Hi all,

I have a need for a short program:

Given a drive letter, it would recursively search through all directories,
"generating" each filename that it encounters (need to pass each filename to
a function).

Can't help but think this "utility" already exists but f**ked if I can find
it.

Any help would be greatly appreciated. Thanks in advance
Nov 14 '05 #1
Share this Question
Share on Google+
34 Replies


P: n/a

"kevin.watters" <ke******@hotmail.com> a écrit dans le message de
news:s9********************@news20.bellglobal.com. ..
Hi all,

I have a need for a short program:

Given a drive letter, it would recursively search through all directories,
"generating" each filename that it encounters (need to pass each filename to a function).

Can't help but think this "utility" already exists but f**ked if I can find it.

Any help would be greatly appreciated. Thanks in advance


This has nothing to do with the C language kevin. You are off topic.
But anyway here it is:

DIR C:\ /B /S /AA >tmpfile

tmpfile will contain all files in the drive.

Nov 14 '05 #2

P: n/a
Thanks for the prompt reply Jacob, I guess I should be clearer..

This program has to reside on a floppy, and cannot alter the user machine in
any way, so the storing of the tmpfile is a problem (with 68000 files, it is
5M).

I need something that can be used "on the fly", that is, without storing the
filenames. I wrote something in VBScript, called the C function 68000
times, took 6.5 hours, so no good :)

Hope this makes things clearer, and thanks again.

Kevin
"jacob navia" <ja***@jacob.remcomp.fr> wrote in message
news:cd**********@news-reader4.wanadoo.fr...

"kevin.watters" <ke******@hotmail.com> a écrit dans le message de
news:s9********************@news20.bellglobal.com. ..
Hi all,

I have a need for a short program:

Given a drive letter, it would recursively search through all directories, "generating" each filename that it encounters (need to pass each
filename to
a function).

Can't help but think this "utility" already exists but f**ked if I can

find
it.

Any help would be greatly appreciated. Thanks in advance


This has nothing to do with the C language kevin. You are off topic.
But anyway here it is:

DIR C:\ /B /S /AA >tmpfile

tmpfile will contain all files in the drive.

Nov 14 '05 #3

P: n/a

"kevin.watters" <ke******@hotmail.com> wrote in message

I have a need for a short program:

Given a drive letter, it would recursively search through all directories,
"generating" each filename that it encounters (need to pass each filename
to a function).

Unfortunately you can't do this in ANSI C. There are no "directory"
functions. This is pretty bad and I don't know what the justification is.

However there will certainly be a "readdir" or similar function specific to
the platform you use which accomplishes what you are trying to achieve.

Nov 14 '05 #4

P: n/a
Thanks Malcolm,

I figured there would be some extra headers required...

The problem is that we only know the operating system is Windows 98 or
better, but still Microsoft. Not sure what C libraries are standard with
the 98 for example ( the earliest). Haven't looked at C in a while, if I
needed extra libraries, could I put them on the floppy along with the .exe
program, or would they have to reside on the host machine itself? I added a
clarification in the post above, not sure if you noticed it.

Thanks again and any idea where I could find some sample code that does
something similar to what I need, even if not ANSI C (but close enough it
will run on a Microsoft system)

Kevin
"Malcolm" <ma*****@55bank.freeserve.co.uk> wrote in message
news:cd**********@newsg3.svr.pol.co.uk...

"kevin.watters" <ke******@hotmail.com> wrote in message

I have a need for a short program:

Given a drive letter, it would recursively search through all directories, "generating" each filename that it encounters (need to pass each filename to a function).
Unfortunately you can't do this in ANSI C. There are no "directory"
functions. This is pretty bad and I don't know what the justification is.

However there will certainly be a "readdir" or similar function specific

to the platform you use which accomplishes what you are trying to achieve.

Nov 14 '05 #5

P: n/a
If you need the code of a function that does exactly what you want look at
"Programming with lcc-win32" section 1.33. It describes a program that
calls a function with the name of each file in a drive/directory. All source
is included.

The tutorial of lcc-win32 can be downloaded (at no charge) from
www.cs.virginia.edu/~lcc-win32
Click in the "Tutorial" link
Nov 14 '05 #6

P: n/a

A: Because it's hard as the very devil to read.
Q: Hates it? Why?
A: You top-posted. We hates it, Precious.
Q: Did I do anything else wrong?
A: You ignored the most important part of Jacob's response,
the part about your question being completely off-topic.
Q: Why is everyone so grumpy? What have I done wrong?

kevin.watters wrote:
Thanks for the prompt reply Jacob, I guess I should be clearer..

This program has to reside on a floppy, and cannot alter the user machine in
any way, so the storing of the tmpfile is a problem (with 68000 files, it is
5M).

I need something that can be used "on the fly", that is, without storing the
filenames. I wrote something in VBScript, called the C function 68000
times, took 6.5 hours, so no good :)

Hope this makes things clearer, and thanks again.

Kevin
"jacob navia" <ja***@jacob.remcomp.fr> wrote in message
news:cd**********@news-reader4.wanadoo.fr...
"kevin.watters" <ke******@hotmail.com> a écrit dans le message de
news:s9********************@news20.bellglobal.co m...
Hi all,

I have a need for a short program:

Given a drive letter, it would recursively search through all
directories,
"generating" each filename that it encounters (need to pass each


filename
to
a function).

Can't help but think this "utility" already exists but f**ked if I can


find
it.

Any help would be greatly appreciated. Thanks in advance


This has nothing to do with the C language kevin. You are off topic.
But anyway here it is:

DIR C:\ /B /S /AA >tmpfile

tmpfile will contain all files in the drive.




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

Nov 14 '05 #7

P: n/a
"kevin.watters" <ke******@hotmail.com> writes:
Hi all,

I have a need for a short program:

Given a drive letter, it would recursively search through all directories,
"generating" each filename that it encounters (need to pass each filename to
a function).

Can't help but think this "utility" already exists but f**ked if I can find
it.


Try a Windows-specific newsgroup; you'll get better advice than we can
give you here.

--
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.
Nov 14 '05 #8

P: n/a
Terribly sorry, Eric, new to this, thought I could get some help, didn't
necesarily expect courtesy.

I appreciate Jacob's response, I wasn't clear enough in explaining that I
require a C program to provide the "dir" functionality, rather than a DOS
command. Which I tried to explain in another post. How can it be off
topic if I need a C program? And what is a top post?

Thanks.
"Eric Sosman" <Er*********@sun.com> wrote in message
news:40**************@sun.com...

A: Because it's hard as the very devil to read.
Q: Hates it? Why?
A: You top-posted. We hates it, Precious.
Q: Did I do anything else wrong?
A: You ignored the most important part of Jacob's response,
the part about your question being completely off-topic.
Q: Why is everyone so grumpy? What have I done wrong?

kevin.watters wrote:
Thanks for the prompt reply Jacob, I guess I should be clearer..

This program has to reside on a floppy, and cannot alter the user machine in any way, so the storing of the tmpfile is a problem (with 68000 files, it is 5M).

I need something that can be used "on the fly", that is, without storing the filenames. I wrote something in VBScript, called the C function 68000
times, took 6.5 hours, so no good :)

Hope this makes things clearer, and thanks again.

Kevin
"jacob navia" <ja***@jacob.remcomp.fr> wrote in message
news:cd**********@news-reader4.wanadoo.fr...
"kevin.watters" <ke******@hotmail.com> a écrit dans le message de
news:s9********************@news20.bellglobal.co m...
Hi all,

I have a need for a short program:

Given a drive letter, it would recursively search through all
directories,
"generating" each filename that it encounters (need to pass each


filename
to
a function).

Can't help but think this "utility" already exists but f**ked if I can


find
it.

Any help would be greatly appreciated. Thanks in advance


This has nothing to do with the C language kevin. You are off topic.
But anyway here it is:

DIR C:\ /B /S /AA >tmpfile

tmpfile will contain all files in the drive.


--
Er*********@sun.com
Nov 14 '05 #9

P: n/a
Thanks jacob, I will take a look at it, but just to be sure...

I have the function that accepts the filename, I need some program to
generate a list, that I can grab one at a time, of all the files on, for
example, the C drive...

Kevin
"jacob navia" <ja***@jacob.remcomp.fr> wrote in message
news:cd**********@news-reader1.wanadoo.fr...
If you need the code of a function that does exactly what you want look at
"Programming with lcc-win32" section 1.33. It describes a program that
calls a function with the name of each file in a drive/directory. All source is included.

The tutorial of lcc-win32 can be downloaded (at no charge) from
www.cs.virginia.edu/~lcc-win32
Click in the "Tutorial" link

Nov 14 '05 #10

P: n/a
Hi Keith,

I didn't think a Windows newsgroup would have the required expertise in C
that I find here, but I could be wrong. I didn't think it was a windows
specific issue, it just happens that the systems to be scanned are
guarenteed to be Windows. I guess the point is, that it would be easy with
a Linux system, but harder with windows system?

Kevin
"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...
"kevin.watters" <ke******@hotmail.com> writes:
Hi all,

I have a need for a short program:

Given a drive letter, it would recursively search through all directories, "generating" each filename that it encounters (need to pass each filename to a function).

Can't help but think this "utility" already exists but f**ked if I can find it.
Try a Windows-specific newsgroup; you'll get better advice than we can
give you here.

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

Nov 14 '05 #11

P: n/a
On Wed, 14 Jul 2004 18:49:12 +0200, "jacob navia"
<ja***@jacob.remcomp.fr> wrote:

"kevin.watters" <ke******@hotmail.com> a écrit dans le message de
news:s9********************@news20.bellglobal.com ...
Hi all,

I have a need for a short program:

Given a drive letter, it would recursively search through all directories,
"generating" each filename that it encounters (need to pass each filename

to
a function).

Can't help but think this "utility" already exists but f**ked if I can

find
it.

Any help would be greatly appreciated. Thanks in advance


This has nothing to do with the C language kevin. You are off topic.
But anyway here it is:

DIR C:\ /B /S /AA >tmpfile

tmpfile will contain all files in the drive.

devtest6 >DIR C:\ /B /S /AA >tmpfile
sh: DIR: not found.

Doesn't seem to work.

--
Al Balmer
Balmer Consulting
re************************@att.net
Nov 14 '05 #12

P: n/a
On Wed, 14 Jul 2004 18:25:45 +0100, "Malcolm"
<ma*****@55bank.freeserve.co.uk> wrote:

"kevin.watters" <ke******@hotmail.com> wrote in message

I have a need for a short program:

Given a drive letter, it would recursively search through all directories,
"generating" each filename that it encounters (need to pass each filename
to a function).

Unfortunately you can't do this in ANSI C. There are no "directory"
functions. This is pretty bad and I don't know what the justification is.

Think about it. What if there are no directories?

--
Al Balmer
Balmer Consulting
re************************@att.net
Nov 14 '05 #13

P: n/a
kevin.watters wrote:
Terribly sorry, Eric, new to this, thought I could get some help, didn't
necesarily expect courtesy.

I appreciate Jacob's response, I wasn't clear enough in explaining that I
require a C program to provide the "dir" functionality, rather than a DOS
command. Which I tried to explain in another post. How can it be off
topic if I need a C program? And what is a top post?


Top-posting is what you've just done *again*. Here's
another pseudo-verb that might interest you: "to Google"
is to use a Web browser to visit http://www.google.com and
to enter a word or phrase in the nice little box and to
click on the "Search" button. If you Google for the phrase
"top-post" you will learn the answer to your final question.
You will learn it, in fact, from the very first link. Go!

The question "How can it be off topic if I need a C
program" is probably a little too involved for simple
Googling. But consider: C is a general-purpose language,
meaning that it can be used for a wide variety of purposes.
I may want a C program to model the electrical impulses that
flow (oh, so slowly) in the spaces behind my eyes and
between my ears, but that doesn't make neurobiology questions
topical here. I may want a C program to play bridge, but
that doesn't make the Stayman convention topical here. You
may want a C program to catalog all the files in all the
directories on a disk drive, but since the C language and
library knows nothing about (1) directories, (2) disk drives,
or (3) drive letters ... are you beginning to get the drift?

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

Nov 14 '05 #14

P: n/a
Congratulations on your eloquence.

Could you have not just said:

Please do not top-post and here is the answer to your question:

the C language and library knows nothing about (1) directories, (2) disk
drives,
or (3) drive letters , sort of like Malcolm did?

Thanks.
"Eric Sosman" <Er*********@sun.com> wrote in message
news:40**************@sun.com...
kevin.watters wrote:
Terribly sorry, Eric, new to this, thought I could get some help, didn't
necesarily expect courtesy.

I appreciate Jacob's response, I wasn't clear enough in explaining that I require a C program to provide the "dir" functionality, rather than a DOS command. Which I tried to explain in another post. How can it be off
topic if I need a C program? And what is a top post?


Top-posting is what you've just done *again*. Here's
another pseudo-verb that might interest you: "to Google"
is to use a Web browser to visit http://www.google.com and
to enter a word or phrase in the nice little box and to
click on the "Search" button. If you Google for the phrase
"top-post" you will learn the answer to your final question.
You will learn it, in fact, from the very first link. Go!

The question "How can it be off topic if I need a C
program" is probably a little too involved for simple
Googling. But consider: C is a general-purpose language,
meaning that it can be used for a wide variety of purposes.
I may want a C program to model the electrical impulses that
flow (oh, so slowly) in the spaces behind my eyes and
between my ears, but that doesn't make neurobiology questions
topical here. I may want a C program to play bridge, but
that doesn't make the Stayman convention topical here. You
may want a C program to catalog all the files in all the
directories on a disk drive, but since the C language and
library knows nothing about (1) directories, (2) disk drives,
or (3) drive letters ... are you beginning to get the drift?

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

Nov 14 '05 #15

P: n/a
[top-posting unraveled]
"kevin.watters" <ke******@hotmail.com> writes:
"Keith Thompson" <ks***@mib.org> wrote in message
Try a Windows-specific newsgroup; you'll get better advice than we can
give you here.


I didn't think a Windows newsgroup would have the required expertise in C
that I find here, but I could be wrong. I didn't think it was a windows
specific issue, it just happens that the systems to be scanned are
guarenteed to be Windows. I guess the point is, that it would be easy with
a Linux system, but harder with windows system?


Yes, it is a Windows specific issue. There is no portable C solution
to your problem.

There are several comp.os.ms-windows.programmer.* newsgroups; try
whichever one of them seems most appropriate. (My best guess is
comp.os.ms-windows.programmer.win32, but your guess is probably better
than mine.)

I suppose it's not immediately obvious that a question about Windows
programming in C is topical in comp.os.ms-windows.programmer.win32 but
off-topic in comp.lang.c, but it is.

--
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.
Nov 14 '05 #16

P: n/a
In article <f8********************@news20.bellglobal.com>
kevin.watters <ke******@hotmail.com> writes:
... I guess the point is, that it would be easy with
a Linux system, but harder with windows system?


No: the point is that the answer is *different* for Windows and
Linux. Moreover, neither the Windows solution nor the Linux solution
will work on VMS; and the VMS solution will not work on any of
those, nor on AmigaDOS; and so on.

Of course, it is difficult to know a priori whether some technique
will work on "all systems that conform to S" (for whatever system
S you choose) -- but the question "is there an S-specific method
to do this" is on topic in any group, even if the answer is "no".

Here in comp.lang.c the appropriate "specific" is the C Standard,
and the answer to the question "is there a Standard C method to
recursively enumerate all directories" is "no".

Fortunately, there *are* specific methods for all POSIX systems
(including Linux), and (different) specific methods for Windows,
etc. (But for something like IBM's MVS, it gets quite complicated.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
Nov 14 '05 #17

P: n/a
kevin.watters wrote:
Congratulations on your eloquence.

Could you have not just said:

Please do not top-post and here is the answer to your question:

the C language and library knows nothing about (1) directories, (2) disk
drives,
or (3) drive letters , sort of like Malcolm did?

Thanks.


You have proved once again that you can't learn.
Top-posting is when your replies are posted
before or "on top" of the previous post.

Try fixing your newsreader or newsposting program
and try again.

Did you read the FAQ or Welcome.txt yet?
See the links below.
--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.raos.demon.uk/acllc-c++/faq.html
Other sites:
http://www.josuttis.com -- C++ STL Library book

Nov 14 '05 #18

P: n/a

"Alan Balmer" <al******@att.net> wrote in message
Unfortunately you can't do this in ANSI C. There are no "directory"
functions. This is pretty bad and I don't know what the justification is.

Think about it. What if there are no directories?

Then you'd just return an empty list.
Nov 14 '05 #19

P: n/a
Malcolm wrote:
"Alan Balmer" <al******@att.net> wrote in message
Unfortunately you can't do this in ANSI C. There are no "directory"
functions. This is pretty bad and I don't know what the justification is.


Think about it. What if there are no directories?


Then you'd just return an empty list.


What if the directories have multiple entries for the
same file, in the manner of those Windows versions that
support both "long" and "DOS" file names? If you return
all the entries you enumerate many files twice. If you
return only the "DOS" names you deprive the user of the
benefits of the "long" names. If you suppress the "DOS"
names of files that also have "long" names, you exasperate
the users who need to get at the "DOS" names. No one
strategy suits all scenarios, so suddenly you've got to
expand the API somehow.

Or suppose files have version numbers, as in OpenVMS?
VMS itself, of course, has ways to get at all versions of
a file, just the oldest, just the newest, and so on -- but
to get at those capabilities, you've got to expand the API
yet again.

Or suppose files appear several times in a directory
using something like Unix' hard links. To deal with this
intelligently, you again need to expand the API, at least
with some means of determining whether two directory entries
refer to the same inode.

The only language I've personally used that tried to
invent a directory abstraction wide enough to cover all these
cases (and more) was Common LISP -- and believe me, the
edifice was more impressive for its size and complexity than
for its utility. A lot of hard work by very smart people
produced something only a certified genius could use in any
but the simplest settings. Go look it up; it's eye-opening.

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

Nov 14 '05 #20

P: n/a

"Eric Sosman" <Er*********@sun.com> a écrit dans le message de
news:40**************@sun.com...
Malcolm wrote:
"Alan Balmer" <al******@att.net> wrote in message
Unfortunately you can't do this in ANSI C. There are no "directory"
functions. This is pretty bad and I don't know what the justification is.

Think about it. What if there are no directories?

Then you'd just return an empty list.


What if the directories have multiple entries for the
same file, in the manner of those Windows versions that
support both "long" and "DOS" file names? If you return
all the entries you enumerate many files twice. If you
return only the "DOS" names you deprive the user of the
benefits of the "long" names. If you suppress the "DOS"
names of files that also have "long" names, you exasperate
the users who need to get at the "DOS" names. No one
strategy suits all scenarios, so suddenly you've got to
expand the API somehow.


I explained the solution in the tutorial article where I wrote
a function to scan files. (Section 1.33)

The solution is to use function pointers and let the user
figure out what he/she wants.

Easy isn't it?

No API. You just call a user defined function.

[snip]
The only language I've personally used that tried to
invent a directory abstraction wide enough to cover all these
cases (and more) was Common LISP -- and believe me, the
edifice was more impressive for its size and complexity than
for its utility. A lot of hard work by very smart people
produced something only a certified genius could use in any
but the simplest settings. Go look it up; it's eye-opening.


It is the wrong alley.

The solution is to use function pointers.

That is VERY EASY in C. It is one of the most powerful features
of C. The way you pass function tokens carrying an incredible
amount of context with just a few machine instructions.

There is NO BEST API, it is better that each usage involves
writing a small function that does exactly what you want.

www.cs.virginia.ed/~lcc-win32

Nov 14 '05 #21

P: n/a
On Wed, 14 Jul 2004 22:23:10 +0100, "Malcolm"
<ma*****@55bank.freeserve.co.uk> wrote:

"Alan Balmer" <al******@att.net> wrote in message
>Unfortunately you can't do this in ANSI C. There are no "directory"
>functions. This is pretty bad and I don't know what the justification is.
>

Think about it. What if there are no directories?

Then you'd just return an empty list.

I can see that I should not have provided a starting point for the
thinking. I withdraw that, and change it to just

Think about it.

--
Al Balmer
Balmer Consulting
re************************@att.net
Nov 14 '05 #22

P: n/a
In <cd*********@news1.newsguy.com> Chris Torek <no****@torek.net> writes:
In article <f8********************@news20.bellglobal.com>
kevin.watters <ke******@hotmail.com> writes:
... I guess the point is, that it would be easy with
a Linux system, but harder with windows system?


No: the point is that the answer is *different* for Windows and
Linux. Moreover, neither the Windows solution nor the Linux solution
will work on VMS; and the VMS solution will not work on any of
those, nor on AmigaDOS; and so on.


Actually, a POSIX-based solution will work everywhere POSIX is implemented
and this includes Linux, Windows, VMS, MVS and many others.

It just happens that the right place for discussing a POSIX-based solution
is not c.l.c.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #23

P: n/a
In <7v********************************@4ax.com> Alan Balmer <al******@att.net> writes:
On Wed, 14 Jul 2004 18:25:45 +0100, "Malcolm"
<ma*****@55bank.freeserve.co.uk> wrote:

"kevin.watters" <ke******@hotmail.com> wrote in message

I have a need for a short program:

Given a drive letter, it would recursively search through all directories,
"generating" each filename that it encounters (need to pass each filename
to a function).

Unfortunately you can't do this in ANSI C. There are no "directory"
functions. This is pretty bad and I don't know what the justification is.

Think about it. What if there are no directories?


Then, opendir() fails. Just like time() fails if there is no real time
clock.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #24

P: n/a
jacob navia wrote:
"Eric Sosman" <Er*********@sun.com> a écrit dans le message de

What if the directories have multiple entries for the
same file, in the manner of those Windows versions that
support both "long" and "DOS" file names? If you return
all the entries you enumerate many files twice. If you
return only the "DOS" names you deprive the user of the
benefits of the "long" names. If you suppress the "DOS"
names of files that also have "long" names, you exasperate
the users who need to get at the "DOS" names. No one
strategy suits all scenarios, so suddenly you've got to
expand the API somehow.


I explained the solution in the tutorial article where I wrote
a function to scan files. (Section 1.33)

The solution is to use function pointers and let the user
figure out what he/she wants.

Easy isn't it?

No API. You just call a user defined function.


The example in your tutorial (a recursive directory-tree
walker) simply passes the problem along to a user-supplied
callback function, still unsolved and without any information
to assist in its solution. The callback function (in your
design) receives nothing at all but the file name as taken
from the directory. The function receives no hint that the
name might be an alias for another name (and certainly no
indication of *which* other name).

You write, correctly, that "there are many options as to
what information should be provided to the user," -- so you
reduce the options by providing as little information as
you possibly can. You ask "Is he interested in the size of
the file" and you decline to provide the size. "Or in the
date," you ask, and omit the date. "Who knows?" Certainly
not the callback function, until and unless it decides to
engage in platform-specific non-portable shenanigans.

"The most flexible solution is the best," you write, but
this isn't flexibility: it's obliviousness. You haven't
solved the problems; you've just decided to ignore them.

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

Nov 14 '05 #25

P: n/a

"Eric Sosman" <Er*********@sun.com> a écrit dans le message de
news:40************@sun.com...
jacob navia wrote:
"Eric Sosman" <Er*********@sun.com> a écrit dans le message de

The example in your tutorial (a recursive directory-tree
walker) simply passes the problem along to a user-supplied
callback function, still unsolved and without any information
to assist in its solution. The callback function (in your
design) receives nothing at all but the file name as taken
from the directory. The function receives no hint that the
name might be an alias for another name (and certainly no
indication of *which* other name).

You can get ALL kinds of information starting with the file name
including size, aliases, dates, etc etc etc.

Your function is suipposed to zero in the parts of this
wealth of info that you need.

The only thing the find files function should do is just that:

FIND THOSE FILES. PERIOD.

There is no other sensible way as you yourself remarked in
the message you posted in this forum.

The solution I propose gives the user complete flexibility as to which
information should be asked for.

jacob
Nov 14 '05 #26

P: n/a

"Eric Sosman" <Er*********@sun.com> wrote in message

What if the directories have multiple entries for the
same file, in the manner of those Windows versions that
support both "long" and "DOS" file names? If you return
all the entries you enumerate many files twice. If you
return only the "DOS" names you deprive the user of the
benefits of the "long" names. If you suppress the "DOS"
names of files that also have "long" names, you exasperate
the users who need to get at the "DOS" names. No one
strategy suits all scenarios, so suddenly you've got to
expand the API somehow.

Or suppose files have version numbers, as in OpenVMS?
VMS itself, of course, has ways to get at all versions of
a file, just the oldest, just the newest, and so on -- but
to get at those capabilities, you've got to expand the API
yet again.

Or suppose files appear several times in a directory
using something like Unix' hard links. To deal with this
intelligently, you again need to expand the API, at least
with some means of determining whether two directory entries
refer to the same inode.

The only language I've personally used that tried to
invent a directory abstraction wide enough to cover all these
cases (and more) was Common LISP -- and believe me, the
edifice was more impressive for its size and complexity than
for its utility. A lot of hard work by very smart people
produced something only a certified genius could use in any
but the simplest settings. Go look it up; it's eye-opening.

As far as I see it the concept is simple enough, you want to "list all
available files" that can be passed to fopen().
The problem is that on all but the smallest systems this produces a list
that is way too long, certainly for human usage and often for computer use
as well. So you need some system of reducing the number of files in scope,
which most OSes do by providing a tree-like hierarchy.

That leads you to problems such as trees containing links, the handling of
the directory itself (is it simply another file?), files with two names or
present in several versions, and probably more that you haven't enumerated
(zip files?).

I think what you would have to do is keep the simpicity of the interface

char **listfiles(int *N)

( list all files available for reading )

However you also need to provide a filter to cut the list down to size.

char **listfiles(struct filter *filt, int *N)

Passing NULL will literally list all available files (though you do need
some solution to the DOS two-names problem). Filling fields will enable you
to filter - and obvious one would be "list only current directory", "list
only latest versions", "don't list directories" could be other members.

Designing a really good filter wouldn't be easy and would require knowledge
of the many different systems out there, but I don't see producing something
usable as an insuperable problem.

Nov 14 '05 #27

P: n/a
On Wed, 14 Jul 2004 15:12:16 -0400, in comp.lang.c , "kevin.watters"
<ke******@hotmail.com> wrote:
Congratulations on your eloquence.


And on your denseness. Youve been asked several times now to stop fscking
well top-posting. So do it already.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Nov 14 '05 #28

P: n/a
"jacob navia" <ja***@jacob.remcomp.fr> writes:
"Eric Sosman" <Er*********@sun.com> a écrit dans le message de
news:40************@sun.com...
jacob navia wrote:
"Eric Sosman" <Er*********@sun.com> a écrit dans le message de

The example in your tutorial (a recursive directory-tree
walker) simply passes the problem along to a user-supplied
callback function, still unsolved and without any information
to assist in its solution. The callback function (in your
design) receives nothing at all but the file name as taken
from the directory. The function receives no hint that the
name might be an alias for another name (and certainly no
indication of *which* other name).

You can get ALL kinds of information starting with the file name
including size, aliases, dates, etc etc etc.


But you provide no clue about *how* to get that information.

You provide (I presume; I haven't looked at it) a generic interface,
using user-supplied callback functions, that lets a program traverse
the names of all the files in a directory tree. There's nothing wrong
with that, it sounds like a useful thing. (An interface that
generates a sequence of names without using callback functions would
probably be equally useful, and might give the calling program better
control.) But you brought it up in the context of a question about
how to deal with multiple entries for the same file, DOS names
vs. long names, etc., implying that you provide a solution for that.

How do you deal with names that are aliases for other names? The
answer is simple, just leave it up to the user. Of course the answer
is simple; it just doesn't answer the question.

Unfortunately, there is no answer that is simple and actually
addresses the question.

--
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.
Nov 14 '05 #29

P: n/a
"Malcolm" <ma*****@55bank.freeserve.co.uk> writes:
[...]
I think what you would have to do is keep the simpicity of the interface

char **listfiles(int *N)

( list all files available for reading )

However you also need to provide a filter to cut the list down to size.

char **listfiles(struct filter *filt, int *N)

Passing NULL will literally list all available files (though you do need
some solution to the DOS two-names problem). Filling fields will enable you
to filter - and obvious one would be "list only current directory", "list
only latest versions", "don't list directories" could be other members.

Designing a really good filter wouldn't be easy and would require knowledge
of the many different systems out there, but I don't see producing something
usable as an insuperable problem.


This is similar to what the Unix "find" program does. If you want to
design such an interface, take a look at the command-line options to
"find"; the ones that control which files are selected should indicate
a subset of the information you'll need in "struct filter". (Of
course, "find" is Unix-specific. Much of the interface is probably
generic enough for similar systems like Windows and VMS, but it's
going to break down on more exotic systems.)

--
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.
Nov 14 '05 #30

P: n/a

"Keith Thompson" <ks***@mib.org> a écrit dans le message de
news:ln************@nuthaus.mib.org...
"jacob navia" <ja***@jacob.remcomp.fr> writes:
"Eric Sosman" <Er*********@sun.com> a écrit dans le message de
news:40************@sun.com...
jacob navia wrote:
"Eric Sosman" <Er*********@sun.com> a écrit dans le message de The example in your tutorial (a recursive directory-tree
walker) simply passes the problem along to a user-supplied
callback function, still unsolved and without any information
to assist in its solution. The callback function (in your
design) receives nothing at all but the file name as taken
from the directory. The function receives no hint that the
name might be an alias for another name (and certainly no
indication of *which* other name).

You can get ALL kinds of information starting with the file name
including size, aliases, dates, etc etc etc.


But you provide no clue about *how* to get that information.

You provide (I presume; I haven't looked at it) a generic interface,
using user-supplied callback functions, that lets a program traverse
the names of all the files in a directory tree. There's nothing wrong
with that, it sounds like a useful thing. (An interface that
generates a sequence of names without using callback functions would
probably be equally useful, and might give the calling program better
control.)


I thought about that but the generated list is several MB of storage
for small drives. For big drives with 40-50Gig in a partition
or even those 120GB partitions now possible that would scale
very badly.

I thought that a solution without that much intermediate storage
would be more efficient and I think it is...

I reflected about this problem really.
But you brought it up in the context of a question about
how to deal with multiple entries for the same file, DOS names
vs. long names, etc., implying that you provide a solution for that.
There is an API for that under Win32: GetShortName.
There are several other APIs for each thing you could ever
think about asking in this context. Finding information about
a file is a different (and simpler) problem than finding the files

Modularity implies keeping a routine centered about its main task
and avoid those "do it all" routines. Finding the aliases is just an API
away, finding the file size, etc the same.

How do you deal with names that are aliases for other names? The
answer is simple, just leave it up to the user. Of course the answer
is simple; it just doesn't answer the question.
A file can have a short and a long name (if you use the old and
obsolete FAT32 stuff). There is an API for that.
Unfortunately, there is no answer that is simple and actually
addresses the question.


My thesis is that "the question" can't be answered with a single
"do it all" solution. There are SO MANY possibilities that it is just
not doable, see the comparison with common lisp in another
message.

This is the solution for qsort too. There are too many ways of
answering the question "which comes first" for any data structure
whatsoever. A user defined function is the only way out.

Nov 14 '05 #31

P: n/a
"jacob navia" <ja***@jacob.remcomp.fr> writes:
"Keith Thompson" <ks***@mib.org> a écrit dans le message de
news:ln************@nuthaus.mib.org...

[...]
You provide (I presume; I haven't looked at it) a generic interface,
using user-supplied callback functions, that lets a program traverse
the names of all the files in a directory tree. There's nothing wrong
with that, it sounds like a useful thing. (An interface that
generates a sequence of names without using callback functions would
probably be equally useful, and might give the calling program better
control.)


I thought about that but the generated list is several MB of storage
for small drives. For big drives with 40-50Gig in a partition
or even those 120GB partitions now possible that would scale
very badly.

I thought that a solution without that much intermediate storage
would be more efficient and I think it is...

I reflected about this problem really.


There's no reason the interface has to provide the whole list at once,
any more than fread() has to provide the entire content of a file at
once. You could provide a function that initializes the query and
returns some kind of handle encoding its current state, and another
function that, given a handle, returns the next file name (or NULL if
there are no more). This makes it easier for the client to do things
like terminate the traversal early (though you can certainly design a
callback interface to handle that).

But regardless of the details of how you provide the sequence, there
are still a number of implementation-specific issues that have to be
addressed, even before you worry about how the client is going to
handle each name. In what order are the entries going to be returned,
and can the user control the order? If there are multiple entries for
a single physical file, does the sequence include all of them or just
one? Do you include directory names? What about other entities that
might exist in the filesystem's namespace (named pipes, devices,
etc. ad nauseam). What about "hidden" files, whatever that might mean
for a given system? What about multiple versions of the same file, as
in VMS? What if files are added or removed during the traversal?

These are all rhetorical questions; I ask them not because I'm looking
for answers, but to illustrate the complexity of the task.

Separating the task into two parts, getting a list of files and doing
whatever you want with each one, is a sensible approach, but each part
of the task is still extraordinarily complex if you're trying to do it
portably. A non-portable solution is likely to be much simpler but
inappropriate for this newsgroup.

--
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.
Nov 14 '05 #32

P: n/a
kal
"jacob navia" <ja***@jacob.remcomp.fr> wrote in message news:<cd**********@news-reader1.wanadoo.fr>...
My thesis is that "the question" can't be answered with a single
"do it all" solution. There are SO MANY possibilities that it is just
not doable, see the comparison with common lisp in another
message.


The OP had taken the advice given here and posted the question
at a different forum where he has been provided with platform
specific suggesstions.

IMHO the suggestions are simple and sufficient.
Nov 14 '05 #33

P: n/a
>> You provide (I presume; I haven't looked at it) a generic interface,
using user-supplied callback functions, that lets a program traverse
the names of all the files in a directory tree. There's nothing wrong
with that, it sounds like a useful thing. (An interface that
generates a sequence of names without using callback functions would
probably be equally useful, and might give the calling program better
control.)


I thought about that but the generated list is several MB of storage
for small drives. For big drives with 40-50Gig in a partition
or even those 120GB partitions now possible that would scale
very badly.


It is possible, for extremely pathological circumstances, for the
list of file names on a drive to exceed the capacity of that drive.
(or all of its drives plus RAM plus CD-ROM drives plus ROM).

Consider a lot of small files very deep in the directory structure,
so that most of the file names begin with (this is really supposed
to be all on one line, but split up for posting):
/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaa
/bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbb
/cccccccccccccccccccccccccccccccccccccccccccccccccc ccccccccccccccccccccccccccc
/dddddddddddddddddddddddddddddddddddddddddddddddddd ddddddddddddddddddddddddddd
/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee eeeeeeeeeeeeeeeeeeeeeeeeeee
/ffffffffffffffffffffffffffffffffffffffffffffffffff fffffffffffffffffffffffffff
/gggggggggggggggggggggggggggggggggggggggggggggggggg ggggggggggggggggggggggggggg
/hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh hhhhhhhhhhhhhhhhhhhhhhhhhhh
/iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii iiiiiiiiiiiiiiiiiiiiiiiiiii
/jjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj jjjjjjjjjjjjjjjjjjjjjjjjjjj
/kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk kkkkkkkkkkkkkkkkkkkkkkkkkkk
/something

There are also some very *REAL* systems where getting a list of all
file names takes hours or even days (think about a large news server,
especially one where every post is kept in a separate file, with
terabytes of storage).

Gordon L. Burditt
Nov 14 '05 #34

P: n/a
In article <7v********************************@4ax.com>,
Alan Balmer <al******@att.net> wrote:
On Wed, 14 Jul 2004 18:25:45 +0100, "Malcolm"
<ma*****@55bank.freeserve.co.uk> wrote:

"kevin.watters" <ke******@hotmail.com> wrote in message

I have a need for a short program:

Given a drive letter, it would recursively search through all directories,
"generating" each filename that it encounters (need to pass each filename
to a function).

Unfortunately you can't do this in ANSI C. There are no "directory"
functions. This is pretty bad and I don't know what the justification is.

Think about it. What if there are no directories?


Or what if you have 200,000 files in 50,000 directories, and while your
code recursively searches through all directories, some other program
moves a few directories around?
Nov 14 '05 #35

This discussion thread is closed

Replies have been disabled for this discussion.