Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 (USS@Tek, v1.1) based on 4.3bsd-beta 6/6/85; site tekla.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!tektronix!teklds!dadla!tekla!jamesp
From: jamesp@tekla.UUCP (James Perkins)
Newsgroups: net.micro.amiga
Subject: Re: AmigaDos...
Message-ID: <528@tekla.UUCP>
Date: Wed, 30-Apr-86 12:39:52 EDT
Article-I.D.: tekla.528
Posted: Wed Apr 30 12:39:52 1986
Date-Received: Sat, 3-May-86 18:30:20 EDT
References: <1076@h-sc1.UUCP> <160@cbmvax.cbmvax.cbm.UUCP>
Reply-To: jamesp@tekla.UUCP (James Perkins)
Distribution: net
Organization: Jupiter Phase, Beaverton, OR
Lines: 58

In article <1076@h-sc1.UUCP> breuel@h-sc1.UUCP (thomas breuel) writes:
>A complaint, and two questions:
>
>I have philosophical problems with the AmigaDos file system.
>The file system appears to be optimised for finding a named entry
>quickly and for making directories small and cheap: the directories
>are hashed and do not contain the filenames. This means that for
>
>						Thomas.

Thomas goes on to say we should eventually replace the AmigaDOS file system
with something more UN*X-like.

I do not disagree with you at all, Thomas, but I can think of a
possible quick hack to speed up getting a directory listing from the
shell, or matching wildcards.  This idea comes from a fls 'fast ls'
program on our VAX BSD UN*X system here at work.

I am assuming that AmigaDOS keeps "last modified dates" for each file
and each directory, and that the "last modified date" of the directory
is updated only when the directory contents change.  (DISCLAIMER: I do
not own an AMIGA [yet], nor have I perused the refernce manuals in any
great detail, so I may be speaking completely out of my a**.)

It would require a "get_file_names(matchstring)" routine which expects
to find a 'lsfile' in each directory, which contains all the names of
the files in the directory.  1: If there is no lsfile present in the
directory to be listed, it would build a new one by polling all the
files in the directory for thier filenames.  Then one would 2:  compare
the last modified date of the 'lsfile' to the last modified date of the
directory -- if the directory was newer than the lsfile, a new lsfile
would be generated by getting the filenames out of each file; then
proceed to step 3: the contents of lsfile is a list of all filenames in
the directory -- now get_file_names() searches this list with whatever
pattern(s) you give it, and returns a pointer to some static list of
the filenames found.  This will be slow each time you add or delete
files in each directory, as it has to rebuild the list of filenames,
but relatively fast if the directory contents are static.  This would
make it possible to browse through the directories (oh, what's over
there) instead of dreading each list.

In all reality, of course, this is just a hacked-up logical addition to
the directory structure, and if the filename data were stored IN the
directories, then there would not be a need to maintain a seperate
database of names.  Still, having a "name database" could allow scans
of the directory's contents be MUCH faster, having to only open 2 files
in the optimal case, instead of 20 or 30.

-- 

		 _|_				James T. Perkins
	  __|__ |___| |\     Terror
	  |___|	|___| | \      on the		tektronix!orstcs!jamesp
	  |___| |___| |  \	 high		tektronix!dadla!jamesp
	 _|___| |___| |___\	   seas
	/...\_____|___|____\_/			4635 S.W. Hillside Drive
	\   o o o o o o o  /			Portland, Oregon 97221
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~