/*-1* SPDX-License-Identifier: BSD-3-Clause2*3* Copyright (c) 1992 Keith Muller.4* Copyright (c) 1992, 19935* The Regents of the University of California. All rights reserved.6*7* This code is derived from software contributed to Berkeley by8* Keith Muller of the University of California, San Diego.9*10* Redistribution and use in source and binary forms, with or without11* modification, are permitted provided that the following conditions12* are met:13* 1. Redistributions of source code must retain the above copyright14* notice, this list of conditions and the following disclaimer.15* 2. Redistributions in binary form must reproduce the above copyright16* notice, this list of conditions and the following disclaimer in the17* documentation and/or other materials provided with the distribution.18* 3. Neither the name of the University nor the names of its contributors19* may be used to endorse or promote products derived from this software20* without specific prior written permission.21*22* THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND23* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE24* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE25* ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE26* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL27* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS28* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)29* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT30* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY31* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF32* SUCH DAMAGE.33*/3435/*36* data structures and constants used by the different databases kept by pax37*/3839/*40* Hash Table Sizes MUST BE PRIME, if set too small performance suffers.41* Probably safe to expect 500000 inodes per tape. Assuming good key42* distribution (inodes) chains of under 50 long (worse case) is ok.43*/44#define L_TAB_SZ 2503 /* hard link hash table size */45#define F_TAB_SZ 50503 /* file time hash table size */46#define N_TAB_SZ 541 /* interactive rename hash table */47#define D_TAB_SZ 317 /* unique device mapping table */48#define A_TAB_SZ 317 /* ftree dir access time reset table */49#define MAXKEYLEN 64 /* max number of chars for hash */5051/*52* file hard link structure (hashed by dev/ino and chained) used to find the53* hard links in a file system or with some archive formats (cpio)54*/55typedef struct hrdlnk {56char *name; /* name of first file seen with this ino/dev */57dev_t dev; /* files device number */58ino_t ino; /* files inode number */59u_long nlink; /* expected link count */60struct hrdlnk *fow;61} HRDLNK;6263/*64* Archive write update file time table (the -u, -C flag), hashed by filename.65* Filenames are stored in a scratch file at seek offset into the file. The66* file time (mod time) and the file name length (for a quick check) are67* stored in a hash table node. We were forced to use a scratch file because68* with -u, the mtime for every node in the archive must always be available69* to compare against (and this data can get REALLY large with big archives).70* By being careful to read only when we have a good chance of a match, the71* performance loss is not measurable (and the size of the archive we can72* handle is greatly increased).73*/74typedef struct ftm {75int namelen; /* file name length */76time_t mtime; /* files last modification time */77off_t seek; /* location in scratch file */78struct ftm *fow;79} FTM;8081/*82* Interactive rename table (-i flag), hashed by orig filename.83* We assume this will not be a large table as this mapping data can only be84* obtained through interactive input by the user. Nobody is going to type in85* changes for 500000 files? We use chaining to resolve collisions.86*/8788typedef struct namt {89char *oname; /* old name */90char *nname; /* new name typed in by the user */91struct namt *fow;92} NAMT;9394/*95* Unique device mapping tables. Some protocols (e.g. cpio) require that the96* <c_dev,c_ino> pair will uniquely identify a file in an archive unless they97* are links to the same file. Appending to archives can break this. For those98* protocols that have this requirement we map c_dev to a unique value not seen99* in the archive when we append. We also try to handle inode truncation with100* this table. (When the inode field in the archive header are too small, we101* remap the dev on writes to remove accidental collisions).102*103* The list is hashed by device number using chain collision resolution. Off of104* each DEVT are linked the various remaps for this device based on those bits105* in the inode which were truncated. For example if we are just remapping to106* avoid a device number during an update append, off the DEVT we would have107* only a single DLIST that has a truncation id of 0 (no inode bits were108* stripped for this device so far). When we spot inode truncation we create109* a new mapping based on the set of bits in the inode which were stripped off.110* so if the top four bits of the inode are stripped and they have a pattern of111* 0110...... (where . are those bits not truncated) we would have a mapping112* assigned for all inodes that has the same 0110.... pattern (with this dev113* number of course). This keeps the mapping sparse and should be able to store114* close to the limit of files which can be represented by the optimal115* combination of dev and inode bits, and without creating a fouled up archive.116* Note we also remap truncated devs in the same way (an exercise for the117* dedicated reader; always wanted to say that...:)118*/119120typedef struct devt {121dev_t dev; /* the orig device number we now have to map */122struct devt *fow; /* new device map list */123struct dlist *list; /* map list based on inode truncation bits */124} DEVT;125126typedef struct dlist {127ino_t trunc_bits; /* truncation pattern for a specific map */128dev_t dev; /* the new device id we use */129struct dlist *fow;130} DLIST;131132/*133* ftree directory access time reset table. When we are done with with a134* subtree we reset the access and mod time of the directory when the tflag is135* set. Not really explicitly specified in the pax spec, but easy and fast to136* do (and this may have even been intended in the spec, it is not clear).137* table is hashed by inode with chaining.138*/139140typedef struct atdir {141char *name; /* name of directory to reset */142dev_t dev; /* dev and inode for fast lookup */143ino_t ino;144time_t mtime; /* access and mod time to reset to */145time_t atime;146struct atdir *fow;147} ATDIR;148149/*150* created directory time and mode storage entry. After pax is finished during151* extraction or copy, we must reset directory access modes and times that152* may have been modified after creation (they no longer have the specified153* times and/or modes). We must reset time in the reverse order of creation,154* because entries are added from the top of the file tree to the bottom.155* We MUST reset times from leaf to root (it will not work the other156* direction). Entries are recorded into a spool file to make reverse157* reading faster.158*/159160typedef struct dirdata {161int nlen; /* length of the directory name (includes \0) */162off_t npos; /* position in file where this dir name starts */163mode_t mode; /* file mode to restore */164time_t mtime; /* mtime to set */165time_t atime; /* atime to set */166int frc_mode; /* do we force mode settings? */167} DIRDATA;168169170