Ron Horner points out:

> It seems that when you use ;CREATE during a restore, the
> accts/groups/dirs that are created with default settings.  In fact,
> this bug has been there for years.  I've always used BULDACCT or the
> VEAUDIT COPYACCT, to copy accounts.

First, I don't consider that behavior a bug. How is RESTORE supposed to know
the settings of groups that don't currently exist? It can't possibly know.
The thing I'm referring to as a bug is what Larry wrote:

> It seems that the restore ;/;directory; create does not recreate HFS
> permission the same as they were backed up.

That ;DIRECTORY makes all the difference. My understanding (and correct me
if I'm wrong) is that when you use the ;DIRECTORY option on a RESTORE, all
the ACCOUNT, GROUP, USER, and (presumably) HFS directory info is restored to
the same state they were in when they were STOREd, *before* any files are
restored. Therefore, the only thing a :RESTORE ;/;DIRECTORY;CREATE should
actually create are any user IDs that own files, where the user ID doesn't
exist anymore (or didn't when the STORE was done).

(Side note: This happens when you do a PURGEUSER and don't ALTFILE their
files to another OWNER name. I try to avoid this, and have a script I wrote
to take care of it for me. You can spot a user that was created during a
RESTORE because they have default capabilities of ND,SF,BA,IA and no HOME
group.)

Anyway, I think this is a bug. If there is, in fact, a good copy of the
directory on the store tape, all the proper access rights should be restored
before anything gets a chance to be ;CREATEd. Unless the sequence on a
RESTORE is 1) do CREATEs, 2) restore DIRECTORY, 3) restore FILEs, but that
seems out of order to me.

Patrick
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Patrick Santucci
HPe3000 Systems Administrator
Cornerstone Brands, Inc.

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *