Re: Gator Boxes and Lisp?

[pwtc!cdj@labrea.stanford.edu (Cris Johnson)]

	We have a Gator Box that allows us to use a Sun Workstation as a Mac
	Server.  Unfortunately the Lisp function
	"Do-files-in-directory" seems to break when run on most (but not all)
	directories on the server.  I am not sure if it a Gator Box problem
	or Appleshare problem or Lisp problem.  We don't have seem to have
	problems transferring files with Finder, but my Lisp code does
	generate errors.

	The message I get when I run
	Do-files-in-directory (or files-in-directory) is:

	"
	> Error: Macintosh System File version 6.0.5

	) 1983-90, Apple Computer, Inc.
	All rights reserved.
	> While executing: FILES-IN-DIRECTORY
	"

	I've demacrofied the code and this error gets called in
	  CCL::%DO-FILES-IN-DIRECTORY
	in the line
	  (CCL::%SIGNAL-ERROR #:G30)

	As best i can figure out (and I am no expert!) there are two calls to
	the trap _HGetFileInfo.  If the result to the first call is zero then
	a new file is accessed, otherwise it is assumed that one has run out
	of files.  If it not zero then one drops to a second call to
	HGetFileInfo where a -43 is expected.  The problem I get with the
	server is that this second call might return a zero.

	I kludged the code (see below) so that a zero result won't cause an
	error but that seems to crash our Gator Box when I run it a lot.

	ANY IDEAS?  

	Anyone else running Gator Boxes with Lisp?

	Any toolbox experts out there that can tell me if the ACL code is
	doing the right thing?  Even if it isn't, it should crash the Gator
	Box if the Gator Box software was designed correctly.

	-david

I've also gotten to look at and think about ccl::do-files-in-directory
but because it broke our TOPS/SUN server configuration (in a different
way, alas for you) when we simultaneously upgraded SUN OS and TOPS/UNIX
stuff.

The second check for a -43 return is there because some other nonzero
value might have been returned by register trap 41484 (_HGetFileInfo),
indicating some other system error besides running out of files had
occurred.  There is assumed to be some state persistence between
successive calls to the register trap that seems to be getting clobbered
after your first -43 return (How many parallel user sessions is the
Gatorbox supposed to be able to support - The _HGetFileInfo trap
is supposed to return information on the "next" file in a directory and
be called repeatedly until you run out of files.  If N users were
simultaneously listing files in N directories by sandwiching lots of calls to
_HGetFileInfo together, it seems like the Gatorbox have to retain N indices
into N NFS directories.  Can it do that?).

Things I'd try in your case:
1 - If _HGetFileInfo is returning 0 on the last call, it presumably DID
FIND a file to report on and you could learn about which one by
examining the stack block s.  Splice in something temporarily to repeat
the code that tells you which file it found - Is it one of yours? or
did some other user mabe miss one of theirs?

2- Don't make that last call to _HGetFileInfo.  Instead, save the
value returned by the previous call inside the ccl::%IZEROP call
and use the saved value in place of what the last call to _HGetFileInfo
is supposed to return.  If you got a "wrong" error, this shouldn't leave
you any less illuminated about it.

Wishing you a lot of luck and for word back on what you find.
Cris Johnson
Price Waterhouse Technology Centre
68 Willow Road, Menlo Park, CA 94025

PS - If anyone wants my antiTOPS ACL stuff, let me know.  The TOPS
problem has to do with EVERYTHING in a directory being returned, not just
files.

	;;; here is the kludged version to get a list of files from a
	;;; Unix server serviced by the Gator Box.  It will crash the
	;;; Gator Box sometimes.

	(defun list-of-files (dir)
	  (LET ((I NIL)(files nil))
	    (CCL::WITH-FILE-OR-DIR dir (a b c)
	       (LET ((d 0))
	         (%STACK-BLOCK ((s 80) (e 256))
	           (CCL::%PSTR-POINTER c e)
	           (%PUT-PTR s e 18)
	           (%PUT-WORD s a 22)
	           (%PUT-LONG s b 48)
	           (TAGBODY
	             loop
	             (%PUT-WORD s (SETQ d (CCL::%I+ d 1)) 28)
	             ;;; first call to getfileinfo
	             (IF (CCL::%IZEROP (CCL::%REGISTER-TRAP 41484 264 s))
	               (PROGN
	                 (%PUT-LONG s b 48)
	                 (SETQ I
	                      (CCL::%MAKE-MAC-PATHNAME (%GET-SIGNED-WORD s 22)
	                                                (CCL::%DIRID-TO-FULLDIRNAME
	                                                 (%GET-SIGNED-WORD s 22)
	                                                 (%GET-LONG s 48))
	                                                (%GET-STRING (%GET-PTR s 18))))
	                 (push i files)
	                 (GO loop))))
	;;; The second call to getfileinfo                 
	    (SETQ d (CCL::%REGISTER-TRAP 41484 264 s))
	;;; below is the part I changed.  
	;;; I changed (if (eql d -43) to
	;;;           (if (or (zerop d) (eql d -43))
	;;; because the second call to getfileinfo sometimes returned a zero
	    (IF (or (zerop d) (EQL d -43))
	    NIL
	    (CCL::%SIGNAL-ERROR d))
	   NIL)))
	  files))