Re: Program to retrieve all filenames in drive
From: Malcolm (malcolm_at_55bank.freeserve.co.uk)
Date: 07/15/04
- Next message: Dan Pop: "Re: Tiny C Compiler for Windows Source"
- Previous message: Kevin Bracey: "Re: boolean values and the FAQ"
- In reply to: Eric Sosman: "Re: Program to retrieve all filenames in drive"
- Next in thread: Keith Thompson: "Re: Program to retrieve all filenames in drive"
- Reply: Keith Thompson: "Re: Program to retrieve all filenames in drive"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 15 Jul 2004 18:35:39 +0100
"Eric Sosman" <Eric.Sosman@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.
- Next message: Dan Pop: "Re: Tiny C Compiler for Windows Source"
- Previous message: Kevin Bracey: "Re: boolean values and the FAQ"
- In reply to: Eric Sosman: "Re: Program to retrieve all filenames in drive"
- Next in thread: Keith Thompson: "Re: Program to retrieve all filenames in drive"
- Reply: Keith Thompson: "Re: Program to retrieve all filenames in drive"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
