Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!wuarchive!udel!mmdf
From: andrewt%watsnew.waterloo.edu@cunyvm.cuny.edu
Newsgroups: comp.sys.amiga
Subject: Re: AmigaDos directory knowledge
Message-ID: <5460@nigel.udel.EDU>
Date: 6 Dec 89 15:35:29 GMT
Sender: mmdf@udel.EDU
Lines: 48


> > Then compare wildcard operations.  MS-DOS must still read the entire
 directory, which is
> > still only a few (probably contiguous) sectors.
>
> Here MS-DOS would read 9 files for my C: directory, AmigaDOS would read
> 133.  That's a definite loss to AmigaDOS, even though it took much less time
> to load the directory program in the first place (I'm talking real life
> here; I refuse to use the built-in Dir command under MS-DOS, so I use a
> UNIX-alike LS which must be loaded from disk, same as the Amiga command).
>

It seems to me that the single most common interactive file system
operation is to find a directory listing.  In second place is the use
of wildcards in file names, and running a very close third is the use
of filename completion for any shell that has it (you may disagree
with my rankings).  Under the above example, you lose bigtime with
Amiga's file system, as all of these examples are equivalent to
wildcarding.  I can't complain about finding my commands quickly, but
any shell that hashes its path will speed that up after the first time
anyway.  Why is AmigaDOS castrating its interactive use in favour of
fast command lookup, when the fast command lookup will only effect the
initial use of a command?

Is it possible to have both?  Could the file system store a secondary
file containing only a set of file names?  Even an ascii file would be
fine.  It would require more work for file creation, deletion, and
moving, but it would massively speed up wildcard activities.  It could
be there as a secondary file to the filesystem so losing it would not
be important.  A simple chkdsk-like program could be used to recreate
this file if it became corrupt by finding each file the hard way.

The only other thing you have to do is keep this file out of reach of
programmers.

The disk usage is not really a problem.  With 15 files to a sector, a
disk with 500 files on it will only need 8K to store this information.
I would happily make this trade for the speed it would provide.

Is there something basically wrong with this scheme?  It really sounds
like a horrible kluge in some ways, but it's an issue that needs to be
addressed.

--

Andrew Thomas
andrewt@watsnew.waterloo.edu    Systems Design Eng.     University of Waterloo
"If a million people do a stupid thing, it's still a stupid thing." - Opus