Manual Pages  — CTM_MAIL

Command line arguments for ctm_smail:

-l log
	Instead of appearing on stderr, error diagnostics and informational messages (other than command line errors) are time stamped and written to the file log.
-m maxmsgsize
	Limit the maximum size mail message that ctm_smail is allowed to send. It is approximate since mail headers and other niceties are not counted in this limit. If not specified, it will default to 64000 bytes, leaving room for 1535 bytes of headers before the rumoured 64k mail limit.
-c maxctmsize
	Limit the maximum size delta that will be sent. Deltas bigger that this limit will cause an apology mail message to be sent to the mailing list. This is to prevent massive changes overwhelming users' mail boxes. Note that this is the size before encoding. Encoding causes a 4/3 size increase before mail headers are added. If not specified, there is no limit.
-q queue-dir
	Instead of mailing the delta pieces now, store them in the given directory to be mailed later using ctm_dequeue. This feature allows the mailing of large deltas to be spread out over hours or even days to limit the impact on recipients with limited network bandwidth or small mail spool areas.

ctm-delta is the delta to be sent, and mail-alias is the mailing list to send the delta to. The mail messages are sent using sendmail(8).

Command line arguments for ctm_dequeue:

-l log
	Instead of appearing on stderr, error diagnostics and informational messages (other than command line errors) are time stamped and written to the file log.
-n numchunks
	Limit the number of mail messages that ctm_dequeue will send per run. By default, ctm_dequeue will send one mail message per run.

queuedir is the directory containing the mail messages stored by ctm_smail. Up to numchunks mail messages will be sent in each run. The recipient mailing list is already encoded in the queued files.

It is safe to run ctm_dequeue while ctm_smail is adding entries to the queue, or even to run ctm_smail multiple times concurrently, but a separate queue directory should be used for each tree being distributed. This is because entries are served in alphabetical order, and one tree will be unfairly serviced before any others, based on the delta names, not delta creation times.

Command line arguments for ctm_rmail:

-l log
	Instead of appearing on stderr, error diagnostics and informational messages (other than command line errors) are time stamped and written to the file log.
-p piecedir
	Collect pieces of deltas in this directory. Each piece corresponds to a single mail message. Pieces are removed when complete deltas are built. If this flag is not given, no input files will be read, but completed deltas may still be applied with ctm if the -b flag is given.
-d deltadir
	Collect completed deltas in this directory. Deltas are built from one or more pieces when all pieces are present.
-b basedir
	Apply any completed deltas to this source tree. If this flag is not given, deltas will be stored, but not applied. The user may then apply the deltas manually, or by using ctm_rmail without the -p flag. Deltas will not be applied if they do not match the .ctm_status file in basedir (or if .ctm_status does not exist).
-D
	Delete deltas after successful application by ctm. It is probably a good idea to avoid this flag (and keep all the deltas) as ctm has the ability to recover small groups of files from a full set of deltas.
-f
	Fork and execute in the background while applying deltas with ctm. This is useful when automatically invoking ctm_rmail from sendmail because ctm can take a very long time to complete, causing other people's mail to be delayed, and can in theory cause spurious mail retransmission due to the remote sendmail timing out, or even termination of ctm_rmail by mail filters such as MH's slocal. Do not worry about zillions of background ctm processes loading your machine, since locking is used to prevent more than one ctm invocation at a time.
-u
	Pass the -u flag to the ctm command when applying the complete deltas, causing it to set the modification time of created and modified files to the CTM delta creation time.
-v
	Pass the -v flag to the ctm command when applying the complete deltas, causing a more informative output. All ctm output appears in the ctm_rmail log file.

The file arguments (or stdin, if there are none) are scanned for delta pieces. Multiple delta pieces can be read from a single file, so an entire maildrop can be scanned and processed with a single command.

It is safe to invoke ctm_rmail multiple times concurrently (with different input files), as might happen when sendmail is delivering mail asynchronously. This is because locking is used to keep things orderly.

ctm_smail -m 60000 /wherever/it/is/src-cur.0032.gz src-guys

ctm_rmail -p ~/pieces -d ~/deltas -b /usr/ctm-src-cur $MAIL

receiver-dude: "|ctm_rmail -p /ctm/tmp -d /ctm/deltas -l /ctm/log"
owner-receiver-dude: real_dude@wherever.you.like

ctm_rmail -D -d /ctm/deltas -b /ctm/src-cur -l /ctm/apply.log

PATH=$HOME/bin:$PATH

:0 w
* ^Subject: ctm-mail cvs-cur
| ctm_incoming

#! /bin/sh
PATH="$HOME/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin"
export PATH

cd $HOME/ctm && ctm_rmail -f -p pieces -d deltas -l log -b /ctm

which will deposit all ctm deltas in ~/ctm/deltas, apply them to the tree in /ctm, and drop any failures into your regular mail box. Note the PATH manipulation in ctm_incoming which allows ctm_rmail to execute ctm(1) on the (non-Fx) machine that this example was taken from.

ctm_smail: src-cur.0250.gz 1/2 sent to src-guys

ctm_smail: src-cur.0250.gz 1/2 queued for src-guys

ctm_dequeue: src-cur.0250.gz 1/2 sent

ctm_rmail: src-cur.0250.gz 1/2 stored
ctm_rmail: src-cur.0250.gz 2/2 stored
ctm_rmail: src-cur.0250.gz complete

ctm_rmail: message contains no delta

These messages go to stderr or to the log file. Messages from ctm(1) turn up here too. Error messages should be self explanatory.