3 applychanges, applylog, compactdb, updatedb \- simple client-server replica management
54 .B replica/applychanges
73 These four tools collectively provide simple log-based
74 client-server replica management.
75 The shell scripts described in
77 provide a more polished interface.
79 Both client and server maintain textual databases of file system
80 metadata. Each line is of the form
94 supersede previous ones.
95 A line with the string
99 field annuls all previous entries for that
101 The entries in a file are typically kept sorted by
104 These properties facilitate updating the database atomically
107 reads in a database and writes out an equivalent one,
108 sorted by path and without outdated or annulled records.
110 A replica is further described on the server by a textual
111 log listing creation and deletion of files and changes
112 to file contents and metadata.
113 Each line is of the form:
133 fields are both decimal numbers, providing an ordering
134 for log entries so that incremental tools need not process
135 the whole log each time they are run.
144 a change to a file's contents
146 or a change to a file's metadata
149 is the file path on the client;
151 the path on the server (these are different when the
152 optional fifth field in a proto file line is given;
160 are the files metadata as in the
164 For deletion events, the metadata is that of the deleted file.
165 For other events, the metadata is that after the event.
168 scans the file system rooted at
170 for changes not present in
172 noting them by appending new entries to the database
173 and by writing log events to standard output.
178 to consider only file and metadata changes, ignoring file additions and deletions.
179 By default, the log events have
181 set to the current system time
184 numbers starting at 0.
187 option can be used to specify a different time and starting number.
190 option is given, all database entries and log events will use
192 rather than the actual uids.
195 option (which may be specified multiple times) excludes the named path
196 and all its children from the scan.
199 option is given, the database is not changed and the
203 fields are omitted from the log events;
204 the resulting output is intended to be a human-readable
205 summary of file system activity since the last scan.
208 is used to propagate changes from server to client.
209 It applies the changes listed in a log
210 (read from standard input)
211 to the file system rooted at
213 copying files when necessary from the file system rooted at
217 does not attempt to set the uid on files; the
221 will not overwrite local changes made to replicated files.
222 When it detects such conflicts, by default it prints an error describing
223 the conflict and takes no action.
228 still takes no action for files beginning with the given names,
229 but does so silently and will not
230 report the conflicts in the future.
231 (The conflict is resolved in favor of the client.)
234 is similar but causes
236 to overwrite the local changes.
237 (The conflict is resolved in favor of the server.)
240 is, in some sense, the opposite of
242 it scans the client file system for changes, and applies
243 those changes to the server file system.
245 will not overwrite remote changes made to replicated files.
246 For example, if a file is copied from server to client and subsequently
247 changed on both server and client,
249 will not copy the client's new version to the server, because
250 the server also has a new version.
254 detect the same conflicts; to resolve conflicts reported by
265 keep a client kfs file system up-to-date
266 against a server file system using these tools.
267 First, connect to a CPU server with a high-speed
268 network connection to the file server and scan
269 the server file system, updating the server database and log:
271 repl=$home/lib/replica
272 proto=/sys/lib/sysconfig/proto/portproto
273 db=$repl/srv.portproto.db
274 log=$repl/srv.portproto.log
277 replica/updatedb -p $proto -r /n/$fs -x $repl $db >>$log
278 replica/compactdb $db >/tmp/a && mv /tmp/a $db
281 Then, update the client file system:
283 repl=$home/lib/replica
284 db=$repl/cli.portproto.db
285 log=$repl/srv.portproto.log
289 replica/applylog $db /n/kfs /n/$fs <$log
290 replica/compactdb $db >/tmp/a && mv /tmp/a $db
295 directory is excluded from the sync so that multiple
296 clients can each have their own local database.
299 are essentially a further development of this example.
301 The Plan 9 distribution update program
302 operates similarly, but omits the first scan;
303 it is assumed that the Plan 9 developers run
304 scans manually when the distribution
308 describes this in full.
312 These tools assume that
316 is a good indicator of changes to a file's contents.