Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!mit-eddie!uw-beaver!ubc-cs!cheddar.ucs.ubc.ca!panon
From: panon@cheddar.ucs.ubc.ca (Paul-Andre Panon)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Directories
Summary: ExAll() info wanted
Message-ID: <8786@ubc-cs.UUCP>
Date: 20 Jul 90 06:22:40 GMT
References: <3541@monu1.cc.monash.oz> <13044@cbmvax.commodore.com>
Sender: news@cs.ubc.ca
Reply-To: panon@cheddar.ucs.ubc.ca (Paul-Andre Panon)
Distribution: na
Organization: UBC Computing Centre, Vancouver, B.C., Canada
Lines: 27

In article <13044@cbmvax.commodore.com> jesup@cbmvax (Randell Jesup) writes:
>  For example, the file could be deleted, and another created
>using the same disk block.  If this happened, you could end up "skipping" to
>another directory (very bad on a delete #?....)  2.0 is more resistant to
>this (I think it stops with an error in most cases).
>
>	This is one of the prime reasons we created ExAll.

So, is there filesystem support for ExAll() such that the fs will "sort
and read file headers in a sequential (i.e. only-increasing or only-
decreasing block #'s) manner" when appropriate (ie. OFS or FFS)? This
would have the nice bonus of speeding up directory listings, no?

I guess what I meant was `is ExAll() atomic at the fs level, as well and
do the OFS and FFS take advantage of that?'?

>
>-- 
>Randell Jesup, Keeper of AmigaDos, Commodore Engineering.
>{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com  BIX: rjesup  
>Common phrase heard at Amiga Devcon '89: "It's in there!"


--
      panon@staff.ucs.ubc.ca           or      USERPAP1@UBCMTSG 
or    ppanon@undergrad.cs.ubc.ca       or      USERPAP1@mtsg.ubc.ca
Looking for a .signature? "We've already got one. It is ver-ry ni-sce!"