bartz@elbereth.rutgers.edu (Edward Bartz) (12/06/90)
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? I can invision this working one of two ways... The loc can
always be a directory, in which case, I have to return the contents
on object at a time. In this case, if I get a loc on a file, I respond
with an object_wrong_type error. On the other hand, it could work
like this. A loc is sent on any object, and I am to return all the
objects within the same directory as the loc I am passed. Although
this second option seems less likely, when you have stared at this
stuff long enough, anything seems possible.
THANKS,
Ed
--
UUCP: bartz@elbereth.uucp
BITNET: bartz@rutphy.bitnet
USSnail: 12 Roosevelt St. South River, NJ 08882markv@kuhub.cc.ukans.edu (12/11/90)
> 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? Good question. I ran into this problem from the programmers end. I can tell you that the Amiga drivers ONLY like ExNext on a directory and ONLY if Examine was called first. You can Examine() a file to get the FIB, but (with the Amiga drivers) if then call ExNext() you will crash (maybe only on 2nd ExNext(), can't remember). > I can invision this working one of two ways... The loc can > always be a directory, in which case, I have to return the contents > on object at a time. In this case, if I get a loc on a file, I respond > with an object_wrong_type error. Given the behavior of the Amiga drivers, I wouldn't worry about supporting ExNext() on files, but an error return sure is preferable to a crash. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mark Gooderum /\ \ | / H a p p y Academic Computing Services / v\ -- * -- H o l i d a y s ! :-) University of Kansas /v v\ / | \ /// /__v___\ Only /// /| __ _ Bitnet: MARKV@UKANVAX || \\\ /// /__| |\/| | | _ /_\ makes it Internet: markv@kuhub.cc.ukans.edu \/\/ / | | | | |__| / \ possible ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ccplumb@spurge.uwaterloo.ca (Colin Plumb) (12/16/90)
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