1*0Sstevel@tonic-gate# 2*0Sstevel@tonic-gate# CDDL HEADER START 3*0Sstevel@tonic-gate# 4*0Sstevel@tonic-gate# The contents of this file are subject to the terms of the 5*0Sstevel@tonic-gate# Common Development and Distribution License, Version 1.0 only 6*0Sstevel@tonic-gate# (the "License"). You may not use this file except in compliance 7*0Sstevel@tonic-gate# with the License. 8*0Sstevel@tonic-gate# 9*0Sstevel@tonic-gate# You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE 10*0Sstevel@tonic-gate# or http://www.opensolaris.org/os/licensing. 11*0Sstevel@tonic-gate# See the License for the specific language governing permissions 12*0Sstevel@tonic-gate# and limitations under the License. 13*0Sstevel@tonic-gate# 14*0Sstevel@tonic-gate# When distributing Covered Code, include this CDDL HEADER in each 15*0Sstevel@tonic-gate# file and include the License file at usr/src/OPENSOLARIS.LICENSE. 16*0Sstevel@tonic-gate# If applicable, add the following below this CDDL HEADER, with the 17*0Sstevel@tonic-gate# fields enclosed by brackets "[]" replaced with your own identifying 18*0Sstevel@tonic-gate# information: Portions Copyright [yyyy] [name of copyright owner] 19*0Sstevel@tonic-gate# 20*0Sstevel@tonic-gate# CDDL HEADER END 21*0Sstevel@tonic-gate# 22*0Sstevel@tonic-gate# Copyright (c) 1995 Sun Microsystems, Inc. All Rights Reserved 23*0Sstevel@tonic-gate# 24*0Sstevel@tonic-gate#ident "%W% %E% SMI" 25*0Sstevel@tonic-gate# 26*0Sstevel@tonic-gate# design notes that are likely to be of general (rather than 27*0Sstevel@tonic-gate# merely historical) interest. 28*0Sstevel@tonic-gate 29*0Sstevel@tonic-gateTable of Contents 30*0Sstevel@tonic-gate 31*0Sstevel@tonic-gate Overview what filesync does 32*0Sstevel@tonic-gate 33*0Sstevel@tonic-gate Primary Data Structures 34*0Sstevel@tonic-gate general principles why they exist 35*0Sstevel@tonic-gate key concepts what they represent 36*0Sstevel@tonic-gate data structures major structures and their contents 37*0Sstevel@tonic-gate 38*0Sstevel@tonic-gate Overview of Passes main phases of program execution 39*0Sstevel@tonic-gate 40*0Sstevel@tonic-gate Modules list and descriptions of files 41*0Sstevel@tonic-gate 42*0Sstevel@tonic-gate Studying the Code 43*0Sstevel@tonic-gate active ingredients a reading list of high points 44*0Sstevel@tonic-gate the whole thing a suggested order for everything 45*0Sstevel@tonic-gate 46*0Sstevel@tonic-gate Gross calling structure who calls whom 47*0Sstevel@tonic-gate 48*0Sstevel@tonic-gate Helpful hints good things to know 49*0Sstevel@tonic-gate 50*0Sstevel@tonic-gateOverview 51*0Sstevel@tonic-gate 52*0Sstevel@tonic-gate The purpose of this program is to compare pairs of directory 53*0Sstevel@tonic-gate trees with a baseline snapshot, to determine which files have 54*0Sstevel@tonic-gate changed, and to propagate the changes in order to bring the 55*0Sstevel@tonic-gate trees back into congruency. The baseline snapshot describes 56*0Sstevel@tonic-gate size, ownership, ... for all files that filesync is managing 57*0Sstevel@tonic-gate WHEN THEY WERE LAST IN SYNC. 58*0Sstevel@tonic-gate 59*0Sstevel@tonic-gate The files and directory trees to be compared are determined 60*0Sstevel@tonic-gate by a relatively flexible (user editable) rules file, whose 61*0Sstevel@tonic-gate format (packingrules.4) permits files and or trees to be 62*0Sstevel@tonic-gate specified, explicitly, implicitly, or with wild cards. 63*0Sstevel@tonic-gate There are also provisions for filtering out unwanted files 64*0Sstevel@tonic-gate and for running programs to generate lists of files and 65*0Sstevel@tonic-gate directories to be included or excluded. 66*0Sstevel@tonic-gate 67*0Sstevel@tonic-gate The comparisons begin by comparing the structured name 68*0Sstevel@tonic-gate spaces. For names that appear in both trees, the files 69*0Sstevel@tonic-gate are then compared on the basis of type, size, contents, 70*0Sstevel@tonic-gate ownership and protections. For files that are already 71*0Sstevel@tonic-gate in the baseline snapshot, if the sizes and modification 72*0Sstevel@tonic-gate times have not changed, we do not bother to recheck the 73*0Sstevel@tonic-gate contents. 74*0Sstevel@tonic-gate 75*0Sstevel@tonic-gate The reconciliation process (resolving the differences) 76*0Sstevel@tonic-gate will only propagate a change if it is obvious what should 77*0Sstevel@tonic-gate be done (one side has changed relative to the snapshot, 78*0Sstevel@tonic-gate while the other has not). If there are conflicting changes, 79*0Sstevel@tonic-gate the file is flagged and the user is asked to reconcile the 80*0Sstevel@tonic-gate differences manually. There are, however a few switches 81*0Sstevel@tonic-gate that can be used to constrain the analysis or reconciliation, 82*0Sstevel@tonic-gate or to force one particular side to win in case of a conflict. 83*0Sstevel@tonic-gate 84*0Sstevel@tonic-gate 85*0Sstevel@tonic-gatePrimary Data Structures 86*0Sstevel@tonic-gate 87*0Sstevel@tonic-gate general principles: 88*0Sstevel@tonic-gate we will build up an in-memory tree that represents 89*0Sstevel@tonic-gate the union of the name spaces found in the baseline 90*0Sstevel@tonic-gate and on the source and destination sides. 91*0Sstevel@tonic-gate 92*0Sstevel@tonic-gate keep in mind that the baseline recalls the state of 93*0Sstevel@tonic-gate files THE LAST TIME THEY WERE IN AGREEMENT. If files 94*0Sstevel@tonic-gate have disagreed for a long time, the baseline still 95*0Sstevel@tonic-gate remembers what they were like when they agreed. If 96*0Sstevel@tonic-gate files have never agreed, the baseline has no notions 97*0Sstevel@tonic-gate of how they "used to be". 98*0Sstevel@tonic-gate 99*0Sstevel@tonic-gate key concepts: 100*0Sstevel@tonic-gate a "base pair" is a pair of directories whose 101*0Sstevel@tonic-gate contents (or a subset of whose contents) are to 102*0Sstevel@tonic-gate be syncrhonized. The "base pairs" to be managed 103*0Sstevel@tonic-gate are specified in the packing rules file. 104*0Sstevel@tonic-gate 105*0Sstevel@tonic-gate associated with each "base pair" is a set of rules 106*0Sstevel@tonic-gate that describe which files (under those directories) 107*0Sstevel@tonic-gate are to be kept in sync. Each rule is a list of: 108*0Sstevel@tonic-gate files and or directories to be included 109*0Sstevel@tonic-gate wild cards for files or directories to be included 110*0Sstevel@tonic-gate programs to generate lists of names for inclusion 111*0Sstevel@tonic-gate file names to be ignored 112*0Sstevel@tonic-gate wild cards for file names to be ignored 113*0Sstevel@tonic-gate programs to generate lists of names for ignoring 114*0Sstevel@tonic-gate 115*0Sstevel@tonic-gate as a result of the "evaluation" process we build up 116*0Sstevel@tonic-gate (under each base pair) a tree that represents all of 117*0Sstevel@tonic-gate the files that we are supposed to keep in sync, and 118*0Sstevel@tonic-gate contains everything we need to know about each one 119*0Sstevel@tonic-gate of those files. The structure of the tree mirrors 120*0Sstevel@tonic-gate the directory hierarchy ... actually the union of the 121*0Sstevel@tonic-gate three hiearchies (baseline, source and destination). 122*0Sstevel@tonic-gate 123*0Sstevel@tonic-gate for each file, we record interesting information (type, 124*0Sstevel@tonic-gate size, owner, protection, mod time) and keep separate 125*0Sstevel@tonic-gate note of what these values were: 126*0Sstevel@tonic-gate in the baseline last time two sides agreed 127*0Sstevel@tonic-gate on the source side, as we just examined it 128*0Sstevel@tonic-gate on the destination side, as we just examined it 129*0Sstevel@tonic-gate 130*0Sstevel@tonic-gate data structures: 131*0Sstevel@tonic-gate 132*0Sstevel@tonic-gate there is an ordered list of "base" structures 133*0Sstevel@tonic-gate for each base, we maintain 134*0Sstevel@tonic-gate three lists of associated "rule" descriptions: 135*0Sstevel@tonic-gate inclusion rules 136*0Sstevel@tonic-gate exclusion rules 137*0Sstevel@tonic-gate restriction rules (from the command line) 138*0Sstevel@tonic-gate a "file" tree, representing all files below the bases 139*0Sstevel@tonic-gate a list of statistics to be printed as a summary 140*0Sstevel@tonic-gate 141*0Sstevel@tonic-gate for each "rule", we maintain 142*0Sstevel@tonic-gate some flags describing the type of rule 143*0Sstevel@tonic-gate the character string that is the rule 144*0Sstevel@tonic-gate 145*0Sstevel@tonic-gate for each "file", we maintain 146*0Sstevel@tonic-gate sibling and child pointers to give them tree structure 147*0Sstevel@tonic-gate flags to describe what we have done/should do 148*0Sstevel@tonic-gate "fileinfo" information from the src, dest, and baseline 149*0Sstevel@tonic-gate 150*0Sstevel@tonic-gate in addition there are some fields that are used 151*0Sstevel@tonic-gate to add the file to a list of files requiring 152*0Sstevel@tonic-gate reconciliation and record what happened to it. 153*0Sstevel@tonic-gate 154*0Sstevel@tonic-gate a "fileinfo" structure contains a subset of the information 155*0Sstevel@tonic-gate that we obtain from a stat call: 156*0Sstevel@tonic-gate major/minor/inum 157*0Sstevel@tonic-gate type 158*0Sstevel@tonic-gate link count 159*0Sstevel@tonic-gate ownership, protection, and acls 160*0Sstevel@tonic-gate size 161*0Sstevel@tonic-gate modification time 162*0Sstevel@tonic-gate 163*0Sstevel@tonic-gate there is also, built up during analysis, a reconciliation 164*0Sstevel@tonic-gate list. This is an ordered list of "file" structures which 165*0Sstevel@tonic-gate are believed to descibe files that have changed and require 166*0Sstevel@tonic-gate reconciliation. The ordering is important both for correctness 167*0Sstevel@tonic-gate and to preserve relative modification times. 168*0Sstevel@tonic-gate 169*0Sstevel@tonic-gateOverview of passes: 170*0Sstevel@tonic-gate 171*0Sstevel@tonic-gate pass I (evaluate) 172*0Sstevel@tonic-gate 173*0Sstevel@tonic-gate stat every file that we might be interested in 174*0Sstevel@tonic-gate (on both src/dest sides). This includes walking 175*0Sstevel@tonic-gate the trees under all directories in order to 176*0Sstevel@tonic-gate find out what files exist and stating all of 177*0Sstevel@tonic-gate them. 178*0Sstevel@tonic-gate 179*0Sstevel@tonic-gate the main trick in this pass is that there may be 180*0Sstevel@tonic-gate files we don't want to evaluate (because we are 181*0Sstevel@tonic-gate limiting our attention to specific files and trees). 182*0Sstevel@tonic-gate There is a LISTED flag kept in the database that 183*0Sstevel@tonic-gate tells me whether or not I need to stat/descend any 184*0Sstevel@tonic-gate given node. 185*0Sstevel@tonic-gate 186*0Sstevel@tonic-gate all restrictions and ignores take effect during this pass. 187*0Sstevel@tonic-gate 188*0Sstevel@tonic-gate pass II (analyze) 189*0Sstevel@tonic-gate 190*0Sstevel@tonic-gate given the baseline and all of the current stat information 191*0Sstevel@tonic-gate gained during pass I, figure out what might conceivably 192*0Sstevel@tonic-gate have changed and queue it for pass III. This pass doesn't 193*0Sstevel@tonic-gate try to figure out what happened or who should win ... it 194*0Sstevel@tonic-gate merely identifies candidates for pass III. This pass 195*0Sstevel@tonic-gate ignores any nodes that were not evaluated during pass I. 196*0Sstevel@tonic-gate 197*0Sstevel@tonic-gate the queueing process, however, determines the order in 198*0Sstevel@tonic-gate which the files will be processed in pass III, and the 199*0Sstevel@tonic-gate order is very important. 200*0Sstevel@tonic-gate 201*0Sstevel@tonic-gate pass III (reconcile) 202*0Sstevel@tonic-gate 203*0Sstevel@tonic-gate process the list of candidates, figuring out what has 204*0Sstevel@tonic-gate actually changed and which versions deserve to win. If 205*0Sstevel@tonic-gate is clear what needs doing, we actually do it in this 206*0Sstevel@tonic-gate pass. 207*0Sstevel@tonic-gate 208*0Sstevel@tonic-gateModules 209*0Sstevel@tonic-gate 210*0Sstevel@tonic-gate filesync.h 211*0Sstevel@tonic-gate defines for limits, sizes and return codes 212*0Sstevel@tonic-gate declarations for global variables (mostly cmd-line parms) 213*0Sstevel@tonic-gate defines for default file names 214*0Sstevel@tonic-gate declarations for routines of general interest 215*0Sstevel@tonic-gate 216*0Sstevel@tonic-gate database.h 217*0Sstevel@tonic-gate data-structures for recording rules 218*0Sstevel@tonic-gate data-structures for recording information about files 219*0Sstevel@tonic-gate declarations for routines that operate on/with those structures 220*0Sstevel@tonic-gate 221*0Sstevel@tonic-gate messages.h 222*0Sstevel@tonic-gate the text of all localizable messages 223*0Sstevel@tonic-gate 224*0Sstevel@tonic-gate debug.h 225*0Sstevel@tonic-gate definitions and declarations for routines for error 226*0Sstevel@tonic-gate simulation and bit-map display. 227*0Sstevel@tonic-gate 228*0Sstevel@tonic-gate acls.c 229*0Sstevel@tonic-gate routines to get, set, compare, and display Access Control Lists 230*0Sstevel@tonic-gate action.c 231*0Sstevel@tonic-gate routines to do the real work of copying, deleting, or 232*0Sstevel@tonic-gate changing ownership in order to make one side agree 233*0Sstevel@tonic-gate with the other. 234*0Sstevel@tonic-gate anal.c 235*0Sstevel@tonic-gate routines to examine the in-core list of files and 236*0Sstevel@tonic-gate determine what has changed (and therefore what is 237*0Sstevel@tonic-gate files are candidates for reconciliation). This 238*0Sstevel@tonic-gate analysis includes figuring out which files should 239*0Sstevel@tonic-gate be links rather than copies. 240*0Sstevel@tonic-gate base.c 241*0Sstevel@tonic-gate routines to read and write the baseline file 242*0Sstevel@tonic-gate routines to search and manipulate the in-core base list 243*0Sstevel@tonic-gate debug.c 244*0Sstevel@tonic-gate data structures and routines, used to sumulate errors 245*0Sstevel@tonic-gate and produce debug output, that map between bits (as found 246*0Sstevel@tonic-gate in various flag words) character string names for their 247*0Sstevel@tonic-gate meanings. 248*0Sstevel@tonic-gate 249*0Sstevel@tonic-gate eval.c 250*0Sstevel@tonic-gate routines to build up the internal tree that describes 251*0Sstevel@tonic-gate the status of all of the files that are described 252*0Sstevel@tonic-gate by the current rules. 253*0Sstevel@tonic-gate files.c 254*0Sstevel@tonic-gate routines to manipulate file name arguments, including 255*0Sstevel@tonic-gate wild cards and embedded environment variables. 256*0Sstevel@tonic-gate ignore.c 257*0Sstevel@tonic-gate routines to maintain a list of names or patterns for 258*0Sstevel@tonic-gate files to be ignored, and to check file names against 259*0Sstevel@tonic-gate that list. 260*0Sstevel@tonic-gate main.c 261*0Sstevel@tonic-gate global variables, cmd-line parameter processing, 262*0Sstevel@tonic-gate parameter validation, error reporting, and the 263*0Sstevel@tonic-gate main loop. 264*0Sstevel@tonic-gate recon.c 265*0Sstevel@tonic-gate routines to examine a list of files that appear to 266*0Sstevel@tonic-gate have changed, and figure out what the appropriate 267*0Sstevel@tonic-gate reconciliation course of action is. 268*0Sstevel@tonic-gate rename.c 269*0Sstevel@tonic-gate routines to search the tree to determine whether 270*0Sstevel@tonic-gate or not any creates/deletes are actually renames. 271*0Sstevel@tonic-gate rules.c 272*0Sstevel@tonic-gate routines to read and write the rules file 273*0Sstevel@tonic-gate routines to add rules and enumerate in-core rules 274*0Sstevel@tonic-gate 275*0Sstevel@tonic-gate filecheck.c 276*0Sstevel@tonic-gate not really a part of filesync, but rather a utility 277*0Sstevel@tonic-gate program that is used in the test suite. It extracts 278*0Sstevel@tonic-gate information about files that is not readily available 279*0Sstevel@tonic-gate from other unix commands. 280*0Sstevel@tonic-gate 281*0Sstevel@tonic-gateComments on studying the code 282*0Sstevel@tonic-gate 283*0Sstevel@tonic-gate if you are only interested in the "active ingredients": 284*0Sstevel@tonic-gate 285*0Sstevel@tonic-gate read the above notes on data structures and then 286*0Sstevel@tonic-gate 287*0Sstevel@tonic-gate read the structure declarations in database.h 288*0Sstevel@tonic-gate 289*0Sstevel@tonic-gate read the above notes overviewing the passes 290*0Sstevel@tonic-gate 291*0Sstevel@tonic-gate in recon.c: read reconcile 292*0Sstevel@tonic-gate 293*0Sstevel@tonic-gate this routine almost makes sense on its own, 294*0Sstevel@tonic-gate and it is unquestionably the most important 295*0Sstevel@tonic-gate routine in the entire program. Everything 296*0Sstevel@tonic-gate else just gathers data for reconcile to use, 297*0Sstevel@tonic-gate or updates the books to reflect the changes. 298*0Sstevel@tonic-gate 299*0Sstevel@tonic-gate in eval.c: read evaluate, eval_file, walker, and note_info 300*0Sstevel@tonic-gate 301*0Sstevel@tonic-gate this is the main guts of pass I 302*0Sstevel@tonic-gate 303*0Sstevel@tonic-gate in anal.c: read analyze, check_file, check_changes & queue_file 304*0Sstevel@tonic-gate 305*0Sstevel@tonic-gate this is the main guts of pass II 306*0Sstevel@tonic-gate 307*0Sstevel@tonic-gate if you want to read the whole thing: 308*0Sstevel@tonic-gate 309*0Sstevel@tonic-gate the following routines do fundamentally simple things 310*0Sstevel@tonic-gate in simple ways, and can (for the most part) be understood 311*0Sstevel@tonic-gate in vaccuuo. The things they do are probably sufficiently 312*0Sstevel@tonic-gate obvious that you can probably understand the more interesting 313*0Sstevel@tonic-gate code without having read them at all. 314*0Sstevel@tonic-gate 315*0Sstevel@tonic-gate base.c 316*0Sstevel@tonic-gate rules.c 317*0Sstevel@tonic-gate files.c 318*0Sstevel@tonic-gate debug.c 319*0Sstevel@tonic-gate ignore.c 320*0Sstevel@tonic-gate acls.c 321*0Sstevel@tonic-gate 322*0Sstevel@tonic-gate the following routines constitute the real meat of the 323*0Sstevel@tonic-gate program, and while they are broken into specialized 324*0Sstevel@tonic-gate modules, they probably need to be understood as an 325*0Sstevel@tonic-gate organic whole: 326*0Sstevel@tonic-gate 327*0Sstevel@tonic-gate main.c setup and control 328*0Sstevel@tonic-gate eval.c pass I 329*0Sstevel@tonic-gate anal.c pass II 330*0Sstevel@tonic-gate recon.c pass III 331*0Sstevel@tonic-gate action.c execution and book-keeping 332*0Sstevel@tonic-gate rename.c a special case for a common situation 333*0Sstevel@tonic-gate 334*0Sstevel@tonic-gate 335*0Sstevel@tonic-gateGross calling structure / flow of control 336*0Sstevel@tonic-gate 337*0Sstevel@tonic-gate main.c:main 338*0Sstevel@tonic-gate findfiles 339*0Sstevel@tonic-gate read_baseline 340*0Sstevel@tonic-gate read_rules 341*0Sstevel@tonic-gate if new rules 342*0Sstevel@tonic-gate add_base 343*0Sstevel@tonic-gate add_include 344*0Sstevel@tonic-gate evaluate 345*0Sstevel@tonic-gate analyze 346*0Sstevel@tonic-gate write_baseline 347*0Sstevel@tonic-gate write_summary 348*0Sstevel@tonic-gate 349*0Sstevel@tonic-gate eval.c:evaluate 350*0Sstevel@tonic-gate add_file_to_base 351*0Sstevel@tonic-gate add_glob 352*0Sstevel@tonic-gate add_run 353*0Sstevel@tonic-gate ignore_pgm 354*0Sstevel@tonic-gate ignore_file 355*0Sstevel@tonic-gate ignore_expr 356*0Sstevel@tonic-gate eval_file 357*0Sstevel@tonic-gate 358*0Sstevel@tonic-gate eval.c:eval_file 359*0Sstevel@tonic-gate note_info 360*0Sstevel@tonic-gate nftw 361*0Sstevel@tonic-gate walker 362*0Sstevel@tonic-gate note_info 363*0Sstevel@tonic-gate 364*0Sstevel@tonic-gate anal.c:analyze 365*0Sstevel@tonic-gate check_file 366*0Sstevel@tonic-gate reconcile 367*0Sstevel@tonic-gate 368*0Sstevel@tonic-gate anal.c:check_file 369*0Sstevel@tonic-gate check_changes 370*0Sstevel@tonic-gate queue_file 371*0Sstevel@tonic-gate 372*0Sstevel@tonic-gate 373*0Sstevel@tonic-gate recon.c:reconcile 374*0Sstevel@tonic-gate samedata 375*0Sstevel@tonic-gate samestuff 376*0Sstevel@tonic-gate do_copy 377*0Sstevel@tonic-gate copy 378*0Sstevel@tonic-gate do_like 379*0Sstevel@tonic-gate update_info 380*0Sstevel@tonic-gate do_like 381*0Sstevel@tonic-gate do_remove 382*0Sstevel@tonic-gate 383*0Sstevel@tonic-gateHelpful Hints 384*0Sstevel@tonic-gate 385*0Sstevel@tonic-gate the "file" structure contains a bunch of flags. Many of them 386*0Sstevel@tonic-gate just summarize what we know about the file (e.g. where it was 387*0Sstevel@tonic-gate found). Others are more subtle and control the evaluation 388*0Sstevel@tonic-gate process or the writing out of the baseline file. You can't 389*0Sstevel@tonic-gate really understand the processing unless you understand what 390*0Sstevel@tonic-gate these flags mean. 391*0Sstevel@tonic-gate 392*0Sstevel@tonic-gate F_NEW added by a new rule 393*0Sstevel@tonic-gate 394*0Sstevel@tonic-gate F_LISTED this name was generated by a rule 395*0Sstevel@tonic-gate 396*0Sstevel@tonic-gate F_SPARSE this directory is an intermediate on 397*0Sstevel@tonic-gate the way to a name generated by a rule 398*0Sstevel@tonic-gate and should not be recursively walked. 399*0Sstevel@tonic-gate 400*0Sstevel@tonic-gate F_EVALUATE this node was found in evaluation and 401*0Sstevel@tonic-gate has up-to-date stat information 402*0Sstevel@tonic-gate 403*0Sstevel@tonic-gate F_CONFLICT there is a conflict on this node so 404*0Sstevel@tonic-gate baseline should remain unchanged 405*0Sstevel@tonic-gate 406*0Sstevel@tonic-gate F_REMOVE this node should be purged from the baseline 407*0Sstevel@tonic-gate 408*0Sstevel@tonic-gate F_STAT_ERROR it was impossible to stat this file 409*0Sstevel@tonic-gate (and anything below it) 410*0Sstevel@tonic-gate 411*0Sstevel@tonic-gate the implications of these flags on processing are 412*0Sstevel@tonic-gate 413*0Sstevel@tonic-gate F_NEW, F_LISTED, F_SPARSE 414*0Sstevel@tonic-gate 415*0Sstevel@tonic-gate affect whether or not a particular node should 416*0Sstevel@tonic-gate be included in the evaluation pass. 417*0Sstevel@tonic-gate 418*0Sstevel@tonic-gate in some situations, only new rules are interpreted. 419*0Sstevel@tonic-gate 420*0Sstevel@tonic-gate listed files and directories should be evaluated 421*0Sstevel@tonic-gate and analyzed. sparse directories should not be 422*0Sstevel@tonic-gate recursively enumerated. 423*0Sstevel@tonic-gate 424*0Sstevel@tonic-gate F_EVALUATE 425*0Sstevel@tonic-gate 426*0Sstevel@tonic-gate determines whether or not a node is included 427*0Sstevel@tonic-gate in the analysis pass. Only nodes that have 428*0Sstevel@tonic-gate been evaluated will be analyzed. 429*0Sstevel@tonic-gate 430*0Sstevel@tonic-gate F_CONFLICT, F_REMOVE, F_EVALUATE 431*0Sstevel@tonic-gate 432*0Sstevel@tonic-gate affect how a node should be written back into the baseline file. 433*0Sstevel@tonic-gate 434*0Sstevel@tonic-gate if there is a conflict or we haven't evaluated 435*0Sstevel@tonic-gate a node, we won't update the baseline. 436*0Sstevel@tonic-gate 437*0Sstevel@tonic-gate if a node is marked for removal, it will be 438*0Sstevel@tonic-gate excluded from the baseline when it is written out. 439*0Sstevel@tonic-gate 440*0Sstevel@tonic-gate F_STAT_ERROR 441*0Sstevel@tonic-gate 442*0Sstevel@tonic-gate if we could not get proper status information 443*0Sstevel@tonic-gate about a file (or the tree under it) we cannot, 444*0Sstevel@tonic-gate with any confidence, determine what its state 445*0Sstevel@tonic-gate is or do anything about it. Such files are 446*0Sstevel@tonic-gate flagged as "in conflict". 447*0Sstevel@tonic-gate 448*0Sstevel@tonic-gate it is somewhat kinky that we put error flagged 449*0Sstevel@tonic-gate files on the reconciliation list. We do this 450*0Sstevel@tonic-gate because this is the easiest way to pull them 451*0Sstevel@tonic-gate out for reporting as conflicts. 452*0Sstevel@tonic-gate 453*0Sstevel@tonic-gate 454