[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Question about traps in serving off Unix

    Date: Wed, 18 Mar 1992 12:29 EST
    From: Barry Margolin <barmar@Think.COM>

	Date: Wed, 18 Mar 1992 11:58 EST
	From: Brad Miller <miller@SOL.CS.ROCHESTER.EDU>

	    Date: Wed, 18 Mar 1992 02:52 EST
	    From: barmar@Think.COM (Barry Margolin)

	    The namespace protocol is specific to Symbolics machines, so the 3670 will
	    have to remain the namespace server, so it makes sense to keep the
	    namespace files on that machine, although there is support for keeping
	    namespace files on a Unix file server (but I've never tried it, so can't
	    vouch for it).

	I have; it's broken, don't bother. (Runs into problems with the (lack of)
	version numbers.)

	We do put the reset of sys: on unix machines, with a shadow copy of the
	directories Barry mentions on a UX400s, in order to build worlds on our

    Ahh, here's another issue:

    The top directory of the Unix directory that contains SYS: should have a
    name that ends with ".sct".  By default, Lispm NFS puts explicit version
    numbers on all files within such directories, instead of leaving the
    version number off the newest version.  And when parsing such pathnames,
    it puts the version number into the PATHNAME-VERSION field, so it does a
    reasonable job of emulating LMFS versioning.

Indeed: we do this; the namespace stuff is still broken. I'll also note that
back transation doesn't work very well with UNIX hosts so we also redefine
fs:CHECK-TRANSLATION to always succeed; otherwise if you take advantage of
making the newest version not have an explicit version number (for access
from unix), you get complaints about mumble:frotz;foo.lisp,
mumble:frotz;foo.lisp.newest, and mumble:frotz;foo.lisp.438 (for example)
all translating to the same file.

We also have a patch for FS:SET-LOGICAL-PATHNAME-HOST which had problems
merging defaults with foo.sct directories under unix. 
 Brad Miller		U. Rochester Comp Sci Dept.
 miller@cs.rochester.edu {...allegra!rochester!miller}