source: trunk/minix/commands/pax/tables.h@ 15

Last change on this file since 15 was 9, checked in by Mattia Monga, 14 years ago

Minix 3.1.2a

File size: 7.5 KB
RevLine 
[9]1/*-
2 * Copyright (c) 1992 Keith Muller.
3 * Copyright (c) 1992, 1993
4 * The Regents of the University of California. All rights reserved.
5 *
6 * This code is derived from software contributed to Berkeley by
7 * Keith Muller of the University of California, San Diego.
8 *
9 * Redistribution and use in source and binary forms, with or without
10 * modification, are permitted provided that the following conditions
11 * are met:
12 * 1. Redistributions of source code must retain the above copyright
13 * notice, this list of conditions and the following disclaimer.
14 * 2. Redistributions in binary form must reproduce the above copyright
15 * notice, this list of conditions and the following disclaimer in the
16 * documentation and/or other materials provided with the distribution.
17 * 4. Neither the name of the University nor the names of its contributors
18 * may be used to endorse or promote products derived from this software
19 * without specific prior written permission.
20 *
21 * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
22 * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
23 * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
24 * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
25 * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
26 * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
27 * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
28 * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
29 * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
30 * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
31 * SUCH DAMAGE.
32 *
33 * @(#)tables.h 8.1 (Berkeley) 5/31/93
34 * $FreeBSD: src/bin/pax/tables.h,v 1.10 2004/04/06 20:06:48 markm Exp $
35 */
36
37/*
38 * data structures and constants used by the different databases kept by pax
39 */
40
41/*
42 * Hash Table Sizes MUST BE PRIME, if set too small performance suffers.
43 * Probably safe to expect 500000 inodes per tape. Assuming good key
44 * distribution (inodes) chains of under 50 long (worse case) is ok.
45 */
46#define L_TAB_SZ 2503 /* hard link hash table size */
47#define F_TAB_SZ 50503 /* file time hash table size */
48#define N_TAB_SZ 541 /* interactive rename hash table */
49#define D_TAB_SZ 317 /* unique device mapping table */
50#define A_TAB_SZ 317 /* ftree dir access time reset table */
51#define MAXKEYLEN 64 /* max number of chars for hash */
52
53/*
54 * file hard link structure (hashed by dev/ino and chained) used to find the
55 * hard links in a file system or with some archive formats (cpio)
56 */
57typedef struct hrdlnk {
58 char *name; /* name of first file seen with this ino/dev */
59 dev_t dev; /* files device number */
60 ino_t ino; /* files inode number */
61 u_long nlink; /* expected link count */
62 struct hrdlnk *fow;
63} HRDLNK;
64
65/*
66 * Archive write update file time table (the -u, -C flag), hashed by filename.
67 * Filenames are stored in a scratch file at seek offset into the file. The
68 * file time (mod time) and the file name length (for a quick check) are
69 * stored in a hash table node. We were forced to use a scratch file because
70 * with -u, the mtime for every node in the archive must always be available
71 * to compare against (and this data can get REALLY large with big archives).
72 * By being careful to read only when we have a good chance of a match, the
73 * performance loss is not measurable (and the size of the archive we can
74 * handle is greatly increased).
75 */
76typedef struct ftm {
77 int namelen; /* file name length */
78 time_t mtime; /* files last modification time */
79 off_t seek; /* location in scratch file */
80 struct ftm *fow;
81} FTM;
82
83/*
84 * Interactive rename table (-i flag), hashed by orig filename.
85 * We assume this will not be a large table as this mapping data can only be
86 * obtained through interactive input by the user. Nobody is going to type in
87 * changes for 500000 files? We use chaining to resolve collisions.
88 */
89
90typedef struct namt {
91 char *oname; /* old name */
92 char *nname; /* new name typed in by the user */
93 struct namt *fow;
94} NAMT;
95
96/*
97 * Unique device mapping tables. Some protocols (e.g. cpio) require that the
98 * <c_dev,c_ino> pair will uniquely identify a file in an archive unless they
99 * are links to the same file. Appending to archives can break this. For those
100 * protocols that have this requirement we map c_dev to a unique value not seen
101 * in the archive when we append. We also try to handle inode truncation with
102 * this table. (When the inode field in the archive header are too small, we
103 * remap the dev on writes to remove accidental collisions).
104 *
105 * The list is hashed by device number using chain collision resolution. Off of
106 * each DEVT are linked the various remaps for this device based on those bits
107 * in the inode which were truncated. For example if we are just remapping to
108 * avoid a device number during an update append, off the DEVT we would have
109 * only a single DLIST that has a truncation id of 0 (no inode bits were
110 * stripped for this device so far). When we spot inode truncation we create
111 * a new mapping based on the set of bits in the inode which were stripped off.
112 * so if the top four bits of the inode are stripped and they have a pattern of
113 * 0110...... (where . are those bits not truncated) we would have a mapping
114 * assigned for all inodes that has the same 0110.... pattern (with this dev
115 * number of course). This keeps the mapping sparse and should be able to store
116 * close to the limit of files which can be represented by the optimal
117 * combination of dev and inode bits, and without creating a fouled up archive.
118 * Note we also remap truncated devs in the same way (an exercise for the
119 * dedicated reader; always wanted to say that...:)
120 */
121
122typedef struct devt {
123 dev_t dev; /* the orig device number we now have to map */
124 struct devt *fow; /* new device map list */
125 struct dlist *list; /* map list based on inode truncation bits */
126} DEVT;
127
128typedef struct dlist {
129 ino_t trunc_bits; /* truncation pattern for a specific map */
130 dev_t dev; /* the new device id we use */
131 struct dlist *fow;
132} DLIST;
133
134/*
135 * ftree directory access time reset table. When we are done with with a
136 * subtree we reset the access and mod time of the directory when the tflag is
137 * set. Not really explicitly specified in the pax spec, but easy and fast to
138 * do (and this may have even been intended in the spec, it is not clear).
139 * table is hashed by inode with chaining.
140 */
141
142typedef struct atdir {
143 char *name; /* name of directory to reset */
144 dev_t dev; /* dev and inode for fast lookup */
145 ino_t ino;
146 time_t mtime; /* access and mod time to reset to */
147 time_t atime;
148 struct atdir *fow;
149} ATDIR;
150
151/*
152 * created directory time and mode storage entry. After pax is finished during
153 * extraction or copy, we must reset directory access modes and times that
154 * may have been modified after creation (they no longer have the specified
155 * times and/or modes). We must reset time in the reverse order of creation,
156 * because entries are added from the top of the file tree to the bottom.
157 * We MUST reset times from leaf to root (it will not work the other
158 * direction). Entries are recorded into a spool file to make reverse
159 * reading faster.
160 */
161
162typedef struct dirdata {
163 int nlen; /* length of the directory name (includes \0) */
164 off_t npos; /* position in file where this dir name starts */
165 mode_t mode; /* file mode to restore */
166 time_t mtime; /* mtime to set */
167 time_t atime; /* atime to set */
168 int frc_mode; /* do we force mode settings? */
169} DIRDATA;
Note: See TracBrowser for help on using the repository browser.