11556Srgrimes/*-
21556Srgrimes * Copyright (c) 1992 Keith Muller.
31556Srgrimes * Copyright (c) 1992, 1993
41556Srgrimes *	The Regents of the University of California.  All rights reserved.
51556Srgrimes *
61556Srgrimes * This code is derived from software contributed to Berkeley by
71556Srgrimes * Keith Muller of the University of California, San Diego.
81556Srgrimes *
91556Srgrimes * Redistribution and use in source and binary forms, with or without
101556Srgrimes * modification, are permitted provided that the following conditions
111556Srgrimes * are met:
121556Srgrimes * 1. Redistributions of source code must retain the above copyright
131556Srgrimes *    notice, this list of conditions and the following disclaimer.
141556Srgrimes * 2. Redistributions in binary form must reproduce the above copyright
151556Srgrimes *    notice, this list of conditions and the following disclaimer in the
161556Srgrimes *    documentation and/or other materials provided with the distribution.
171556Srgrimes * 4. Neither the name of the University nor the names of its contributors
181556Srgrimes *    may be used to endorse or promote products derived from this software
191556Srgrimes *    without specific prior written permission.
201556Srgrimes *
211556Srgrimes * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
221556Srgrimes * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
231556Srgrimes * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
241556Srgrimes * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
251556Srgrimes * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
261556Srgrimes * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
271556Srgrimes * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
281556Srgrimes * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
291556Srgrimes * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
301556Srgrimes * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
311556Srgrimes * SUCH DAMAGE.
321556Srgrimes *
331556Srgrimes *	@(#)tables.h	8.1 (Berkeley) 5/31/93
3450471Speter * $FreeBSD$
351556Srgrimes */
361556Srgrimes
371556Srgrimes/*
381556Srgrimes * data structures and constants used by the different databases kept by pax
391556Srgrimes */
401556Srgrimes
411556Srgrimes/*
421556Srgrimes * Hash Table Sizes MUST BE PRIME, if set too small performance suffers.
431556Srgrimes * Probably safe to expect 500000 inodes per tape. Assuming good key
441556Srgrimes * distribution (inodes) chains of under 50 long (worse case) is ok.
451556Srgrimes */
461556Srgrimes#define L_TAB_SZ	2503		/* hard link hash table size */
471556Srgrimes#define F_TAB_SZ	50503		/* file time hash table size */
481556Srgrimes#define N_TAB_SZ	541		/* interactive rename hash table */
491556Srgrimes#define D_TAB_SZ	317		/* unique device mapping table */
501556Srgrimes#define A_TAB_SZ	317		/* ftree dir access time reset table */
511556Srgrimes#define MAXKEYLEN	64		/* max number of chars for hash */
521556Srgrimes
531556Srgrimes/*
541556Srgrimes * file hard link structure (hashed by dev/ino and chained) used to find the
55102230Strhodes * hard links in a file system or with some archive formats (cpio)
561556Srgrimes */
571556Srgrimestypedef struct hrdlnk {
581556Srgrimes	char		*name;	/* name of first file seen with this ino/dev */
591556Srgrimes	dev_t		dev;	/* files device number */
601556Srgrimes	ino_t		ino;	/* files inode number */
611556Srgrimes	u_long		nlink;	/* expected link count */
621556Srgrimes	struct hrdlnk	*fow;
631556Srgrimes} HRDLNK;
641556Srgrimes
651556Srgrimes/*
661556Srgrimes * Archive write update file time table (the -u, -C flag), hashed by filename.
671556Srgrimes * Filenames are stored in a scratch file at seek offset into the file. The
681556Srgrimes * file time (mod time) and the file name length (for a quick check) are
691556Srgrimes * stored in a hash table node. We were forced to use a scratch file because
701556Srgrimes * with -u, the mtime for every node in the archive must always be available
711556Srgrimes * to compare against (and this data can get REALLY large with big archives).
721556Srgrimes * By being careful to read only when we have a good chance of a match, the
731556Srgrimes * performance loss is not measurable (and the size of the archive we can
741556Srgrimes * handle is greatly increased).
751556Srgrimes */
761556Srgrimestypedef struct ftm {
771556Srgrimes	int		namelen;	/* file name length */
781556Srgrimes	time_t		mtime;		/* files last modification time */
7946684Skris	off_t		seek;		/* location in scratch file */
801556Srgrimes	struct ftm	*fow;
811556Srgrimes} FTM;
821556Srgrimes
831556Srgrimes/*
841556Srgrimes * Interactive rename table (-i flag), hashed by orig filename.
851556Srgrimes * We assume this will not be a large table as this mapping data can only be
861556Srgrimes * obtained through interactive input by the user. Nobody is going to type in
871556Srgrimes * changes for 500000 files? We use chaining to resolve collisions.
881556Srgrimes */
891556Srgrimes
901556Srgrimestypedef struct namt {
911556Srgrimes	char		*oname;		/* old name */
921556Srgrimes	char		*nname;		/* new name typed in by the user */
931556Srgrimes	struct namt	*fow;
941556Srgrimes} NAMT;
951556Srgrimes
961556Srgrimes/*
971556Srgrimes * Unique device mapping tables. Some protocols (e.g. cpio) require that the
981556Srgrimes * <c_dev,c_ino> pair will uniquely identify a file in an archive unless they
991556Srgrimes * are links to the same file. Appending to archives can break this. For those
1001556Srgrimes * protocols that have this requirement we map c_dev to a unique value not seen
1011556Srgrimes * in the archive when we append. We also try to handle inode truncation with
1021556Srgrimes * this table. (When the inode field in the archive header are too small, we
1031556Srgrimes * remap the dev on writes to remove accidental collisions).
1041556Srgrimes *
1058855Srgrimes * The list is hashed by device number using chain collision resolution. Off of
1061556Srgrimes * each DEVT are linked the various remaps for this device based on those bits
1071556Srgrimes * in the inode which were truncated. For example if we are just remapping to
1081556Srgrimes * avoid a device number during an update append, off the DEVT we would have
1091556Srgrimes * only a single DLIST that has a truncation id of 0 (no inode bits were
1101556Srgrimes * stripped for this device so far). When we spot inode truncation we create
1111556Srgrimes * a new mapping based on the set of bits in the inode which were stripped off.
1121556Srgrimes * so if the top four bits of the inode are stripped and they have a pattern of
1131556Srgrimes * 0110...... (where . are those bits not truncated) we would have a mapping
1141556Srgrimes * assigned for all inodes that has the same 0110.... pattern (with this dev
1151556Srgrimes * number of course). This keeps the mapping sparse and should be able to store
1161556Srgrimes * close to the limit of files which can be represented by the optimal
1171556Srgrimes * combination of dev and inode bits, and without creating a fouled up archive.
1181556Srgrimes * Note we also remap truncated devs in the same way (an exercise for the
1191556Srgrimes * dedicated reader; always wanted to say that...:)
1201556Srgrimes */
1211556Srgrimes
1221556Srgrimestypedef struct devt {
1231556Srgrimes	dev_t		dev;	/* the orig device number we now have to map */
1241556Srgrimes	struct devt	*fow;	/* new device map list */
1251556Srgrimes	struct dlist	*list;	/* map list based on inode truncation bits */
1261556Srgrimes} DEVT;
1271556Srgrimes
1281556Srgrimestypedef struct dlist {
1291556Srgrimes	ino_t trunc_bits;	/* truncation pattern for a specific map */
1301556Srgrimes	dev_t dev;		/* the new device id we use */
1311556Srgrimes	struct dlist *fow;
1321556Srgrimes} DLIST;
1331556Srgrimes
1341556Srgrimes/*
1351556Srgrimes * ftree directory access time reset table. When we are done with with a
1361556Srgrimes * subtree we reset the access and mod time of the directory when the tflag is
1371556Srgrimes * set. Not really explicitly specified in the pax spec, but easy and fast to
1381556Srgrimes * do (and this may have even been intended in the spec, it is not clear).
1391556Srgrimes * table is hashed by inode with chaining.
1401556Srgrimes */
1411556Srgrimes
1421556Srgrimestypedef struct atdir {
1431556Srgrimes	char *name;	/* name of directory to reset */
1441556Srgrimes	dev_t dev;	/* dev and inode for fast lookup */
1451556Srgrimes	ino_t ino;
1461556Srgrimes	time_t mtime;	/* access and mod time to reset to */
1471556Srgrimes	time_t atime;
1481556Srgrimes	struct atdir *fow;
1491556Srgrimes} ATDIR;
1501556Srgrimes
1511556Srgrimes/*
1521556Srgrimes * created directory time and mode storage entry. After pax is finished during
1531556Srgrimes * extraction or copy, we must reset directory access modes and times that
1541556Srgrimes * may have been modified after creation (they no longer have the specified
1551556Srgrimes * times and/or modes). We must reset time in the reverse order of creation,
1561556Srgrimes * because entries are added  from the top of the file tree to the bottom.
1571556Srgrimes * We MUST reset times from leaf to root (it will not work the other
1581556Srgrimes * direction).  Entries are recorded into a spool file to make reverse
1591556Srgrimes * reading faster.
1601556Srgrimes */
1611556Srgrimes
1621556Srgrimestypedef struct dirdata {
1631556Srgrimes	int nlen;	/* length of the directory name (includes \0) */
1641556Srgrimes	off_t npos;	/* position in file where this dir name starts */
1651556Srgrimes	mode_t mode;	/* file mode to restore */
1661556Srgrimes	time_t mtime;	/* mtime to set */
1671556Srgrimes	time_t atime;	/* atime to set */
1681556Srgrimes	int frc_mode;	/* do we force mode settings? */
1691556Srgrimes} DIRDATA;
170