There is a program, "db_verify", that can be used to read
a pt database, even one that is slightly corrupted. It can be
told to produce an ascii "dump" of the database that contains
every user and group in the database. The output actually
consists of "ptclient" commands, and can be fed to that to
create a database that is (in theory) the same as the original
database. You can edit the ptclient commands, find just the
group you care about, discard the rest of the output, and either
convert it into pts commands, or run it through ptclient.
You should be able to get a copy of this utility by
contacting your Transarc customer support representative.
(It comes with the AFS source, but apparently is considered
a desperation/debugging utility, and doesn't seem to come
with the AFS binary distribution.) "ptclient" may be in the
same class, so ask about that at the same time.
Another possibility would be to run ptserver in a small test cell
just long enough to extract the data from your backup of the pt
database. The file /afs/umich.edu/user/m/d/mdw/wp/uniq.2 contains
very crude notes on how to bring up a small test cell suitable
for this purpose; but you should probably talk with your transarc
customer support representative first before trying this.
You can also write your own utility to read through a pt database file.
The records in the pt database are very straight forward.
The published header files seem to contain all the information
you need to figure it out, but to save you some head
scratching, here are some hints. There is a 64 byte ubik header
(only the first 16 bytes, described by "struct ubik_hdr" in <ubik.h>
are relevant.) This is followed by a 65600 byte database header
(struct prheader in <afs/prserver.h>) which includes the logical
size of the database (.eofPtr). This is followed by 192 byte data
records up to logical file offset eofPtr (described by struct
prentry in prserver.h.) The actual file size may be larger
due to another layer of record blocking that's done inside of ubik.h,
but there is no valid information past the logical end of file. Note
that the ubik header size (64) isn't included in any logical file offsets,
so add 64 to get the physical file offset. Groups, user, free entries,
and continuation records are identified by bits set in low order 6 bits
of .flags. (PRFREE, PRUSER, PRGRP, PRCONT, masked by PRTYPE). If a
user or group contains more than 10 groups or users, continuation
records are employed, chanined by "next" (this is a logical
offset, so remember to add 64 to get the physical file offset.)
The TLA 'NYI' in the header files *may* mean "not yet implemented".
-Marcus Watts
UM ITD PD&D Umich Systems Group
