The Cedar Archivist is a DCedar program that writes files from IFS's to tape and keeps track of where they are. Over the years it has stored about 300,000 files on tape. Each file is written on two tapes, and an entry made in a BTree directory that maps from file names to tape identifications.

Unfortunately, the DCedar BTree is not readable by the PCedar BTree package (problems with byte ordering, etc.). Hence this package was created for PCedar to read (only) a compressed version of the Archivist BTree that is created by the DCedar ArchivistBTree package.

The Archives interface provides procedures for opening, closing and enumerating the directory. (See Archives.mesa.)

Archives.DirectoryName: "/ux/project/archivist/Archives.CompressedDirectory"

The implementation provides two commands for looking at the directory:

enumerates the entire directory, placing its output, 1 line per file, on cmd.out (e.g. use commander output redirection to place the output in a file);

enumerates files matching each of the patterns and places its output on cmd.out in a format similar to that used by the cedar ListFiles command. The patterns should be in brackety syntax. The output format looks like this

The theory is that with the tape identification information you can go to someone who knows something about the Archivist and get the files back.

I really hope you don't need to look at this to use this package!

The compressed directory format supported by this package and the corresponding procedure in DCedar ArchivistBTreeImpl is as follows. The file consists of an arbitrary number of compressed segments (using the F4KS method of D/PCedar Compression) followed by an index. Each segment is the result of compressing the ascii representation of the BTree entries for 500 (except in the last segment) files. The index follows the last segment and contains, for each segment, the first file name in the segment and the position in the file where the segment starts. 32 bit arithmetic quantities are stored as Basics.FWORD's for DCedar/PCedar compatibility. The detailed format is

Since compression streams do not provide explicit end of stream indications, it is crucial that the reader know how many entries to read out of each segment. Since they are all the same except the last, only the entry count for the last segment is stored in the index.