Provided by: shapetools_1.4pl6-11_i386 bug

NAME

       af_archive -- format of archive files in the Attribute Filesystem

SYNOPSIS

       #include <atfs.h>
       #include <afsys.h>

DESCRIPTION

       AtFS  archive  files  are used to store the data and attributes of non-
       busy ASOs.  Beside these, some attributes (including all  user  defined
       attributes) of busy ASOs are stored in AtFS archive files.

       AtFS  maintains  two archive files for each line of development, one to
       hold the standard- and the user defined attributes  and  the  other  to
       hold  the  data  and  change notes.  These files are stored either in a
       subdirectory named AtFS or in a explicitly named directory somewhere in
       your file system.  The two archive files are named
            Attr/<filename>          (attributes) and
            Data/<filename>          (data).

       This  manual  contains  a  short,  exemplary description of the archive
       structure.  All data in AtFS-archives are stored as ASCII-strings.  The
       archives  contain keywords and keyletters. These are set in boldface in
       the following description.  Strings of the form  <field>  describe  the
       purpose of the appropriate field in the archive.

       Here's the structure (the attributes file first):

                                   The Header, ...

       ^BARHD   <archive_format_version>   <no_of_revisions>   <size_of_data>

                                   ... the name ..

       ^BI   <hostname>   <path>   <name>   <type>   <variant(unused)>

                                ... and the owner ..

       ^BO   <owner's_name>   <owner's_host>   <owner's_domain>

              ... followed by some attributes for the busy version ...

       ^BP   <gen_>   <rev_of_physical_predecessor>
       ^BL   <locker's_name>   <locker's_host>   <locker's_domain>   <date_of_last_lock_change>

                ... and the revision list, that contains all standard
                        attributes for non-busy versions. ...

       ^BR   <generation>   <revision>   <state>   <mode>   <variant(unused)>
            ^BA   <author's_name>   <_host>   <_domain>   <locker's_name>   <_host>   <_domain>
            ^BT   <date_of_last_modification>   <_last_access>   <_last_status_change>   ...
                                        ...   <_saving>   <_locking>
            ^BM   <kind_of_representation>   <size_of_file>   <size_of_delta>   ...
                      ...   <gen_>   <rev_of_phys._successor>   <gen_>   <rev_of_phys._predecessor>
       ^BR ...
       ^BR ...

            ... Now follows the list of lists of user defined attributes
        ("-2 -2" indicates the busy version; "@" stands for a null byte). ...

       ^BUSEG
       ^BU -2 -2
       machine=vax@data=fs@@
       ^BU   <gen>   <rev>
       name=value@@
       ^BU ...

       The structure of the datafile:

       Data are represented either by deltas or by complete data-chunks...

       ^BDATA   <archive_format_version>

       ^BN   <gen>   <rev>   <size_of_note>
       --- empty log message ---

       ^BD   <gen>   <rev>   <kind_of_representation>   <size_of_data>
       A typical delta looks like:
       @67723@@@@44@67756@^A14@some text@6635@ and so on.
       Deltas are indicated by a "1" at the "kind_of_representation" field.

       ^BN   <gen>   <rev>   <size_of_note>
       This is a log message

       ^BD   <gen>   <rev>   <kind_of_representation>   <size_of_data>
       A "0" at the "kind_of_representation" field indicates that this
       version is stored completely.

       ^BN ...

       ^BD ...

AUTHOR

       Andreas Lampen, Tech. Univ. Berlin (andy@cs.tu-berlin.de)