1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
|
/*************************************************************************
*
* HTCd - Copyright (C) 1998-2006 Henrik Rydberg
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
*/
HDB/1.2 FILE FORMAT SPECIFICATION Sat Feb 24 18:38:25 MET 2001
MT AND MP SAFE
One single format utilizing memory maps, and which is designed to
work safely between processes and within a multi-threading process.
To accomplish this, there are two types of locking mechanisms -
one inter-process lock in the file header, and one MT lock implemented
the usual way.
The format is robust within each thread, except for changes in the
table structure, which generates fatal error_t errors.
The format includes a finite (32) number of tables, which should not
be a real problem. Besides, a possible change is to move the frame
pointer to a position inside, so that additional header could be
added if needed.
FILEFORMAT in HDB/1.2
BYTES 1.2 NAME DESCRIPTION
32 IDENT Identification header
4 LOCK Inter-process lock
4 MINOR Minor modification state number
4 MAJOR Major modification state number
4 FATAL Fatal modification state number
4 FILESIZE Size of file
4 FILETOP Size of used part
4 TABLES Number of table name strings
4 INDEX Which column is the order column.
32 COMPNAME Comparison name
32*32 TABLENAMES Table names
4 FRAME Start of record data
* RECORDS Record list
4 mem amount of memory for this record
4 caps the capacity of this record - 0 means deleted
mem-8 data The data follows
0 ZEROS The rest of the file is padded with zeros.
The records are always staying where they land; a minor change means
a change in-place, a major change means a change leading to an index
update, which could be a deletion, an insertion. Those are updated at
will, and not seen until wanted. A fatal change is a change in the
table structure, i.e., an insertion or deletion of a table. Also a
table name change counts as fatal. The filesize used to be (earlier
versions) a state needing attention as well, but not anymore.
--
HDB/1.11 FILE FORMAT SPECIFICATION Mon Jan 29 03:51:41 MET 2001
STATIC/DYNAMIC mapping
The header field determines whether the mapping is dynamic or static,
i.e., static mapping creates a shared mmap and edits the records
directly, whereas the dynamic mapping creates a private map and
stores the changes on save only.
The format changed quite a lot after all...
FILEFORMAT in HDB/1.11
BYTES 1.11 NAME DESCRIPTION
32 IDENT Identification header
4 MODNUM Modification number
4 LOCK Soft lock
4 FILESIZE Size of file
4 FILETOP Size of used part
4 FIXED Whether fixed mapping or not
4 TABLES Number of table name strings
4 INDEX Which column is the order column.
32 COMPNAME Comparison name
4 RECORDS Number of records in file.
tables
4,* name table name
4,* defaults default string
4 caps default sizes
[4],* records TABLES[RECORDS]
Size info [4] always refers to the stringref-size, but the number of
bytes actually written is as follows: for fixed maps, it is tabs[].caps,
and for dynamic maps, it is capsize(), which is defined as (n=stringref-size)
(4+n)&~3.
--
HDB/1.10 FILE FORMAT SPECIFICATION Thu Jan 25 00:42:49 MET 2001
The HDB/1.0 format has been used widely in the software
for our group (MST) during the last three years of so.
The HDB/1.1 file format is binary compatible with 1.0,
and merely consists of a formalization, along with a
change in the internal manipulation scheme and a new
hdb editor.
FILE FORMAT IN 1.0 and 1.1
BYTES 1.0/1.1 NAME DESCRIPTION
32/variable HEAD Identification header.
Used to be exactly 32 bytes,
but see no point in that.
4 TABLES Number of table name strings
4 dim bytes in string
* data string data
4 DEFAULTS Number of default strings
4 dim bytes in string
* data string data
4 ORDERBY Which column is the order column.
4 dim Number of bytes in compname.
* data string data
4 RECORDS Number of records in file.
4 tables
4 dim
* data
0/variable FOOTER File ends. Simple Footer.
ADDITIONAL CHANGES BETWEEN 1.0 and 1.1
The major difference - and the rationale for 1.1 - is
the possiblity to edit files directly, as in mmap.
To be able to do this, there is a need to force a minimum
size to each field. This is done by padding the data
with trailing zeros. This is ok since only string data
is stored in the fields, and never binary data. Just think
of it; if it was binary data, it would not be replaced
by something the same size anyways, so thats forbidden
in the direct-editing mode. It makes no difference to
the normal operation.
The default sizes for new fields are taken from the defaults
table, which again is completely compatible. The only
difference is that the zeros are stored as well, and hence
cannot be defined just by the default string, but need an editor
that specifies the sizes.
|
