Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!umich!terminator!pisa.ifs.umich.edu!rees
From: rees@pisa.ifs.umich.edu (Jim Rees)
Newsgroups: comp.sys.apollo
Subject: Re: Merging Registries and Unix Id's
Message-ID: <4e1c1539.1bc5b@pisa.ifs.umich.edu>
Date: 20 Nov 90 01:13:29 GMT
References: <9011191504.AA02324@gw1.ags.bnl.gov>
Sender: usenet@terminator.cc.umich.edu (usenet news)
Reply-To: rees@citi.umich.edu (Jim Rees)
Organization: University of Michigan IFS Project
Lines: 37

In article <9011191504.AA02324@gw1.ags.bnl.gov>, roger@GW1.AGS.BNL.GOV (Roger A. Katz) writes:
  I am about to merge separate internet registries.  I am sure to see numerous examples where
  Joe with unix id 150 is on registry A while Ann with unix id 150 is on registry B.
  Question:
    1. What is the effect on Joe's files when I change his unix id and do nothing else?
    2. What does the /etc/syncids program really accomplish?

One of the really nice advantages of Apollo over other systems is that most
system resources are named internally by UIDs, which are 64 bit numbers
unique for all time.  So Joe and Ann are identified by unique numbers in the
registry, and merging two registries is fundamentally no problem.

Unfortunately, we do have to live in the real world, and that means
assigning Unix IDs to Joe and Ann.  Unix IDs are at most the size of an int,
and on some systems are only the size of a short, so they can't be unique. 
So the registry maintains the Unix ID in addition to the UID.

To get good performance, it's not a good idea to have to go to the registry
every time you stat() a file, so the inode contains the Unix ID in addition
to the UID.  The bad news is that this means the file system can get out of
sync with the registry if you change the UID-to-Unix-ID mapping.

That's where syncids comes in.  It looks at the real ownership of the file,
which is specified by the UID, and looks up in the registry to find out
today's Unix ID to go with that ownership.  Then it sets the Unix ID stored
in the inode to be correct for today's mapping.

The bottom line is that when you find Joe and Ann both have the same Unix
ID, you should re-assign one of them, then when you're all done you should
run syncids over all disks that might contain any files owned by someone
whose Unix ID has changed.  That's it.  No files actually change ownership
(as far as the kernel is concerned).  *** Do not *** chown the files.

The right way to handle this would have been to widen Unix IDs to 64 bits
and make them unique.  That's what Aegis tried to do.  But as we know, Aegis
lost and Unix won, for reasons having nothing to do with UIDs.  So we're
stuck with syncids.