Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!news.cs.indiana.edu!maytag!watmath!watdragon!spurge!ccplumb
From: ccplumb@spurge.uwaterloo.ca (Colin Plumb)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Action_Ex_Next
Keywords: handlers
Message-ID: <1990Dec15.192927.241@watdragon.waterloo.edu>
Date: 15 Dec 90 19:29:27 GMT
References: <Dec.6.09.52.10.1990.3636@elbereth.rutgers.edu>
Sender: daemon@watdragon.waterloo.edu (Owner of Many System Processes)
Distribution: na
Organization: University of Waterloo
Lines: 49

In article <Dec.6.09.52.10.1990.3636@elbereth.rutgers.edu> bartz@elbereth.rutgers.edu (Edward Bartz) writes:
>
>	I have been playing around with device handlers, and have what
>may stupid question.  When handling an Examine next, you are passed a
>loc on an object.  Is that object a directory always? or can it be 
>a file?

The sequence goes
lock = Lock(directory)
Examine(lock, fib);
ExNext(lock,fib) until it returns ERROR_NO_MORE_ENTRIES

ExNext() always expects a lock on a directory and a fib that applies either
to the directory or something in it.

A few notes: The fib_DirEntryType is in fact a copy of the secondary type
of the relavent file header block.  The 1.3 BCPL utilities need those
exact values, not just >0 and <0, and under 2.0 they've added a few others
for links.

Under 1.3, Workbench is given to trashing "unimportant" parts of the fib,
like some of the file information.  Ask Randell Jesup for details.

ExNext is Brain Damaged because there's no "I'm done ExNexting" call.
Talking to Steve Beats, the polite way is to DupLock to get a lock to
examine, step over that, and free the lock, but people don't have to
do that.  There are Manx filename-globbing utilities that free the lock
between calls to ExNext, which is really icky.

If you want to have fun, use "dir opt i" to be able to type commands between
ExNext calls and move the file just listed to a different directory before
going on.  Surprise!  The ExNext gets teleported to the new directory.
Or rename the file withing the current directory.  A big change in hash
values works best, if you have a utility to compute it for you.

(I think deleting the file, and then ensuring the file header block gets
trashed, will guru AmigaDOS due to an access-after-free bug.)

Worse, the old FS simply didn't have enough information to correctly recover
in such cases, because when the file was moved, the pointer to the next file
in the current directory is lost.  You can figure out which hash chain you're
on by the saved filename, but the location within... no go.

FFS fixes much of this, by returning files in header key order, so the
information in a FileInfoBlock is enough to recreate your position in a scan.

ExAll looks like a big improvement, but I haven't got the autodocs yet.
-- 
	-Colin