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