1 | .TH SYNCTREE 1
|
---|
2 | .SH NAME
|
---|
3 | synctree \- synchronize directory trees.
|
---|
4 | .SH SYNOPSIS
|
---|
5 | .nf
|
---|
6 | \fBsynctree\fP [\fB\-iuf\fP] [[\fIuser1\fP@]\fImachine1\fP:]\fIdir1\fP [[\fIuser2\fP@]\fImachine2\fP:]\fIdir2\fP
|
---|
7 | .fi
|
---|
8 | .SH DESCRIPTION
|
---|
9 | .B Synctree
|
---|
10 | synchronizes the directory tree rooted at \fIdir2\fP with \fIdir1\fP. It
|
---|
11 | walks recursively through both trees, and deletes and adds files in
|
---|
12 | \fIdir2\fP to make it equal to \fIdir1\fP. Mode, owner and group are set for
|
---|
13 | each file unless the \fB\-u\fP flag is given. In its normal mode of operation,
|
---|
14 | synctree will ask if it may delete or add directories assuming that you don't
|
---|
15 | want to. Non-directories are simply deleted or added, but synctree will ask if
|
---|
16 | it needs to update a normal file with a default answer of 'y'. Simply typing
|
---|
17 | return will choose the default answer, typing end-of-file is like typing
|
---|
18 | return to this question and all other questions.
|
---|
19 | .PP
|
---|
20 | You can specify a hostname and user-id to be used to access \fIdir1\fP or
|
---|
21 | \fIdir2\fP. Synctree will use \fBrsh\fP(1) to run a copy of itself on
|
---|
22 | the remote machine. The call interface mimics that of \fBrcp\fP(1), but
|
---|
23 | you can use more than one user@machine prefix if you want to make things
|
---|
24 | really interesting.
|
---|
25 | .PP
|
---|
26 | Hard links are enforced, an update is done by first deleting the old file
|
---|
27 | so that links to unknown files are broken. Links to files within \fIdir2\fP
|
---|
28 | will be restored.
|
---|
29 | .PP
|
---|
30 | If either directory contains the file \fB.backup\fP, then this file will
|
---|
31 | be used as an alternate inode table. This allows one to make a backup copy
|
---|
32 | of a file tree full of special files and differing user-ids on a remote
|
---|
33 | machine under an unpriviledged user-id.
|
---|
34 | .PP
|
---|
35 | .SH OPTIONS
|
---|
36 | .TP 5
|
---|
37 | .B \-i
|
---|
38 | Ask for permission (with default answer 'n') to delete or
|
---|
39 | add any file or directory.
|
---|
40 | .TP 5
|
---|
41 | .B \-u
|
---|
42 | Only install newer files, i.e. merge the directory trees.
|
---|
43 | .TP 5
|
---|
44 | .B \-f
|
---|
45 | Don't ask, think 'yes' on any question.
|
---|
46 | .SH "SEE ALSO"
|
---|
47 | .BR remsync (1),
|
---|
48 | .BR cpdir (1),
|
---|
49 | .BR rsh (1),
|
---|
50 | .BR rcp (1),
|
---|
51 | .BR perror (3).
|
---|
52 | .SH DIAGNOSTICS
|
---|
53 | Messages may come from three different processes. One named "Slave" running
|
---|
54 | in \fIdir1\fP, one named "Master" running in \fIdir2\fP, and synctree itself
|
---|
55 | in a mediator role. The mediator will also perform the task of either the
|
---|
56 | master or the slave if one of them is running locally. You need to know this
|
---|
57 | to interpret the error messages coming from one of these processes. The
|
---|
58 | messages are normally based on \fBperror\fP(3). Failure to contact a remote
|
---|
59 | machine will be reported by \fBrsh\fP. \fBSynctree\fP should have a zero
|
---|
60 | exit status if no errors have been encountered.
|
---|
61 | .SH BUGS
|
---|
62 | Directory \fIdir2\fP will be created without asking.
|
---|
63 | .PP
|
---|
64 | The master and slave processes get their error output mixed up sometimes
|
---|
65 | (nice puzzle).
|
---|
66 | .PP
|
---|
67 | The local and remote machine must use the same file type encoding.
|
---|
68 | .PP
|
---|
69 | The link replacement strategy may lead to lack of space on a small device.
|
---|
70 | Let \fBsynctree\fP run to completion and then rerun it to pick up the pieces.
|
---|
71 | .PP
|
---|
72 | Letting the local process keep its "synctree" name may be a mistake.
|
---|
73 | .PP
|
---|
74 | It talks too much.
|
---|
75 | .SH AUTHOR
|
---|
76 | Kees J. Bot, (kjb@cs.vu.nl)
|
---|