1 .\" $NetBSD: mtree.8,v 1.7 1997/10/17 11:46:46 lukem Exp $
3 .\" Copyright (c) 1989, 1990, 1993
4 .\" The Regents of the University of California. All rights reserved.
6 .\" Redistribution and use in source and binary forms, with or without
7 .\" modification, are permitted provided that the following conditions
9 .\" 1. Redistributions of source code must retain the above copyright
10 .\" notice, this list of conditions and the following disclaimer.
11 .\" 2. Redistributions in binary form must reproduce the above copyright
12 .\" notice, this list of conditions and the following disclaimer in the
13 .\" documentation and/or other materials provided with the distribution.
14 .\" 3. All advertising materials mentioning features or use of this software
15 .\" must display the following acknowledgement:
16 .\" This product includes software developed by the University of
17 .\" California, Berkeley and its contributors.
18 .\" 4. Neither the name of the University nor the names of its contributors
19 .\" may be used to endorse or promote products derived from this software
20 .\" without specific prior written permission.
22 .\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
23 .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
24 .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
25 .\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
26 .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
27 .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
28 .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
29 .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
30 .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
31 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
34 .\" @(#)mtree.8 8.2 (Berkeley) 12/11/93
41 .Nd map a directory hierarchy
53 compares the file hierarchy rooted in the current directory against a
54 specification read from the standard input.
55 Messages are written to the standard output for any files whose
56 characteristics do not match the specification, or which are
57 missing from either the file hierarchy or the specification.
59 The options are as follows:
62 Print a specification for the file hierarchy to the standard output.
64 Ignore everything except directory type files.
66 Don't complain about files that are in the file hierarchy, but not in the
69 Read the specification from
71 instead of from the standard input.
73 Add the specified (whitespace or comma separated) keywords to the current
76 Use the ``type'' keyword plus the specified (whitespace or comma separated)
77 keywords instead of the current set of keywords.
79 Use the file hierarchy rooted in
81 instead of the current directory.
83 Remove any files in the file hierarchy that are not described in the
86 Display a single checksum to the standard error output that represents all
87 of the files for which the keyword
90 The checksum is seeded with the specified value.
92 Modify the owner, group, and permissions of existing files to match
93 the specification and create any missing directories.
94 User, group, and permissions must all be specified for missing directories
96 Exit with a status of 0 on success, 1 if any error occurred;
97 a mismatch is not considered to be an error if it was corrected.
101 except a status of 2 is returned if the file hierarchy did not match
104 Don't descend below mount points in the file hierarchy.
107 Specifications are mostly composed of ``keywords'', i.e. strings that
108 that specify values relating to files.
109 No keywords have default values, and if a keyword has no value set, no
110 checks based on it are performed.
112 Currently supported keywords are as follows:
115 The checksum of the file using the default algorithm specified by
120 Ignore any file hierarchy below this file.
122 The file group as a numeric value.
124 The file group as a symbolic name.
126 The file the symbolic link is expected to reference.
128 The current file's permissions as a numeric (octal) or symbolic
131 The number of hard links the file is expected to have.
133 The file is optional; don't complain about the file if it's
134 not in the file hierarchy.
136 The file owner as a numeric value.
138 The file owner as a symbolic name.
140 The size, in bytes, of the file.
142 The last modification time of the file.
144 The type of the file; may be set to any one of the following:
146 .Bl -tag -width Cm -compact
150 character special device
164 The default set of keywords are
174 There are four types of lines in a specification.
176 The first type of line sets a global value for a keyword, and consists of
177 the string ``/set'' followed by whitespace, followed by sets of keyword/value
178 pairs, separated by whitespace.
179 Keyword/value pairs consist of a keyword, followed by an equals sign
180 (``=''), followed by a value, without whitespace characters.
181 Once a keyword has been set, its value remains unchanged until either
184 The second type of line unsets keywords and consists of the string
185 ``/unset'', followed by whitespace, followed by one or more keywords,
186 separated by whitespace.
188 The third type of line is a file specification and consists of a file
189 name, followed by whitespace, followed by zero or more whitespace
190 separated keyword/value pairs.
191 The file name may be preceded by whitespace characters.
192 The file name may contain any of the standard file name matching
193 characters (``['', ``]'', ``?'' or ``*''), in which case files
194 in the hierarchy will be associated with the first pattern that
197 Each of the keyword/value pairs consist of a keyword, followed by an
198 equals sign (``=''), followed by the keyword's value, without
199 whitespace characters.
200 These values override, without changing, the global value of the
201 corresponding keyword.
203 All paths are relative.
204 Specifying a directory will cause subsequent files to be searched
205 for in that directory hierarchy.
206 Which brings us to the last type of line in a specification: a line
207 containing only the string
209 causes the current directory
210 path to ascend one level.
212 Empty lines and lines whose first non-whitespace character is a hash
213 mark (``#'') are ignored.
217 utility exits with a status of 0 on success, 1 if any error occurred,
218 and 2 if the file hierarchy did not match the specification.
220 To detect system binaries that have been ``trojan horsed'', it is recommended
223 be run on the file systems, and a copy of the results stored on a different
224 machine, or, at least, in encrypted form.
227 option should not be an obvious value and the final checksum should not be
228 stored on-line under any circumstances!
231 should be run against the on-line specifications and the final checksum
232 compared with the previous value.
233 While it is possible for the bad guys to change the on-line specifications
234 to conform to their modified binaries, it shouldn't be possible for them
235 to make it produce the same final checksum value.
236 If the final checksum value changes, the off-line copies of the specification
237 can be used to detect which of the binaries have actually been modified.
243 options can be used in combination to create directory hierarchies
244 for distributions and other such things.
246 .Bl -tag -width /etc/mtree -compact
248 system specification directory