Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!decvax!bellcore!ulysses!allegra!princeton!caip!lll-crg!styx!RED.RUTGERS.EDU!AWalker
From: AWalker@RED.RUTGERS.EDU (*Hobbit*)
Newsgroups: mod.computers.vax
Subject: uaf files
Message-ID: <12211208701.60.AWALKER@RED.RUTGERS.EDU>
Date: Sat, 31-May-86 21:32:48 EDT
Article-I.D.: RED.12211208701.60.AWALKER
Posted: Sat May 31 21:32:48 1986
Date-Received: Sun, 1-Jun-86 10:20:46 EDT
Sender: daemon@styx.UUCP
Organization: The ARPA Internet
Lines: 18
Approved: info-vax@sri-kl.arpa

When I upgraded to 4.3 I built the new system tree in an alternate root, so
if 4.3 crashed things would revert to 4.1 until I could come pick up the
wreckage.  I didn't move the UAF but pointed to it with a system/exec/etc
definition of SYSUAF pointing to the old one in the 4.1 tree.  This has the
side effect of preventing you from building a bare SYSUAF.DAT in some other
directory by running Authorize -- it looks for the logical and either uses
the system uaf or barfs because it can't open it.

This seems to be a good way to prevent users from farting around with 
Authorize on their own -- perhaps a good thing in certain environments, but
not really something dangerous.  But suppose I *want* to create a new UAF
file to mess with on this system?  Defining SYSUAF to point to the other
directory I'm messing with doesn't work; Authorize complains about some 
file access type problem.  How do I get around it without blowing away the
system logical name while I create the new UAF file?

_H*
-------