One correspondent thinks that perhaps the news distribution mechanism could be pressed into service for this job. I could have started from C-news, say, instead of from scratch, and have progressively bent C-news to behave like I wanted.
My feeling is that the route was shorter as I did it, from scratch,
that it would have been from C-news. Of course, I could have
removed the heavy administrative details of C-news: the history and
expire, the daemons, the cron entries, etc., then added
the interactive features and specialized behaviors, but all this clean
up would certainly have took energies. Right now, non counting the
subsidiary scripts and shar/unshar sources, the heart of the result
is a single (1200 lines) script written in Perl, which I find fairly
more smaller and maintainable than a patched C-news distribution
would have been.
This is merely a place holder for previous documentation, waiting that I clean it up. You have no interest in reading further down.
Usage: mailsync [ OPTION ] ... [ EMAIL_ADDRESS ] [ DIRECTORY ] or: mailsync [ OPTION ] ... SYNC_DIRECTORY
Option -i simply sends a ihave package, with no bulk files.
Option -n inhibits any destructive operation and mailing.
In the first form of the call, find a synchronisation directory in DIRECTORY aimed towards some EMAIL_ADDRESS, then proceed with this synchronisation directory. EMAIL_ADDRESS may be the name of a file containing a distribution list. If EMAIL_ADDRESS is not specified, all the synchronisation directories at the top level in DIRECTORY are processed in turn. If DIRECTORY is not specified, the current directory is used.
In the second form of the call, proceed only with the given synchronisation directory SYNC_DIRECTORY.
For proceeding with a synchronisation directory, whatever the form of
the call was, this script reads the ident files it contains to set
the local user and directory and the remote user and directory. Then,
selected files under the local directory which are modified in regard
to the corresponding files in the remote directory are turned into a
synchronisation package which is mailed to the remote user.
The list of selected files or directories to synchronize from the
local directory are given in the list file in the synchronisation
directory. If this list file is missing, all files under the the
local directory are synchronized.
What I usually do is to cd at the top of the directory tree to be
synchronized, then to type mailsync without parameters. This will
automatically prepare as many synchronisation packages as there are
mirror systems, then email multipart shars to each of them. Note that
the synchronisation package is not identical for each mirror system,
because they do not usually have the same state of synchronisation.
mailsync will refuse to work if anything needs to be hand cleaned
from a previous execution of mailsync or resync. Check
for some remaining `_syncbulk' or `_synctemp' directory, or
for a `_syncrm' script.
TODO: - interrogate the user if `ident' file missing. - automatically construct the local user address. - create the synchronisation directory on the fly. - avoid duplicating work as far as possible for multiple sends. - have a quicker mode, depending on stamps, not on checksums. - never send core, executables, backups, `.nsf*', `*/_synctemp/*', etc.
Usage: resync [ OPTION ]... TAR_FILE or: resync [ OPTION ]... UNTARED_DIRECTORY
Given a tar file produced by mailsync at some remote end and already reconstructed on this end using unshar, or a directory containing the already untared invoice, apply the synchronization package locally.
Option -n inhibits destroying or creating files, but does everything else. It will in particular create a synchronization directory if necessary, produce the `_syncbulk' directory and the `_syncrm' script.
The synchronization directory for the package is automatically
retrieved or, if not found, created and initialized. resync keeps
telling you what it is doing.
There are a few cases when a resync should not complete without manual intervention. The common case is that several sites update the very same files differently since they were last resync'ed, and then mailsync to each other. The prerequisite checksum will then fail, and the files are then kept into the `_syncbulk' tree, which has a shape similar to the directory tree in which the files where supposed to go. For GNU Emacs users, a very handy package, called emerge, written by Dale Worley <drw@kutta.mit.edu>, helps reconciling two files interactiveley. The `_syncbulk' tree should be explicitely deleted after the hand synchronisation.
Another case of human intervention is when files are deleted at the mailsync'ing site. By choice, all deletions on the receiving side are accumulated in a `_syncrm' script, which is not executed automatically. Explicitely executed, `_syncrm' will remove any file in the receiving tree which does not exist anymore on the sender system. I often edit `_syncrm' before executing it, to remove the unwanted deletions (beware the double negation :-). The script removes itself.
All the temporary files, while resynchronizing, are held in `_synctemp',
which is deleted afterwards; if something goes wrong, this directory
should also be cleaned out by hand. resync will refuse to work if
anything remains to be hand cleaned.
TODO: - interrogates the user if missing receiving directory in `ident'. - allow `remote.sum' to be empty or non-existent.