[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 | */
|
---|
| 57 | typedef 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 | */
|
---|
| 76 | typedef 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 |
|
---|
| 90 | typedef 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 |
|
---|
| 122 | typedef 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 |
|
---|
| 128 | typedef 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 |
|
---|
| 142 | typedef 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 |
|
---|
| 162 | typedef 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;
|
---|