---
name: "af_archive"
section: "5"
platform: "linux"
package: "shapetools"
version: "1.4pl6-15+b1"
release: "Debian 12 (Bookworm)"
platforms: ["linux"]
url: "https://new.carta.tech/af_archive"
---

# af\_archive(5)

## 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)