manページ  — CTM_MAIL

ctm_smail のコマンドラインの引数には以下があります:

-l log
	stderr に出力する代わりに、 (コマンドラインのエラー以外の) エラー診断と情報メッセージ にタイムスタンプを付けた物がファイル log に書き込まれます。
-m maxmsgsize
	ctm_smail が送信できるメールメッセージの最大サイズを制限します。 メールヘッダとその他の細かい物をこの制限に入れていないため およその値となります。 指定されないとデフォルトは、メールの限界と噂される 64k に対して ヘッダのための 1535 バイトを残した 64000 バイトです。
-c maxctmsize
	送信されるデルタの最大サイズを制限します。この制限より大きいデルタは 謝罪メールをメーリングリストに送り出します。 これは大幅な変更でユーザのメールボックスを圧迫してしまうのを 避けるためです。これはエンコードする前のサイズなので注意して下さい。 エンコードされるとメールヘッダを付ける前でサイズは 4/3 倍になります。 指定されないと無制限になります。
-q queue-dir
	デルタのかけらをメールする代わりに、後で ctm_dequeue を使ってメールされるように指定されたディレクトリに格納します。 この機能によって、巨大なデルタを数時間または数日にも渡って分散させ、 ネットワークのバンド幅が狭かったりメールのスプール領域が小さい 受信者へのインパクトを押えることが可能です。

ctm-delta は送信されるデルタで、 mail-alias はデルタを送信するメーリングリストです。 メールメッセージは sendmail(8) を使って送信されます。

ctm_dequeue のコマンドラインの引数には以下があります:

-l log
	stderr に出力する代わりに、 (コマンドラインのエラー以外の) エラー診断と情報メッセージ にタイムスタンプを付けた物がファイル log に書き込まれます。
-n numchunks
	1 回の ctm_dequeue の実行で送信するメールメッセージの数を制限します。 デフォルトでは、 ctm_dequeue は 1 回の実行で 1 つのメールメッセージを送信します。

queuedir は ctm_smail が格納したメールメッセージのあるディレクトリです。 numchunks 個までのメールメッセージが実行ごとに送信されます。 受信者のメーリングリストは、溜められたファイルに すでにエンコードされています。

ctm_smail がキューにエントリを追加している最中や、複数の ctm_smail を並行に実行している最中でも ctm_dequeue を安全に実行できますが、配布される各ツリーごとに独立した キューのディレクトリを使うべきです。 これはエントリがアルファベット順に処理されるので、デルタの 作成時刻ではなく、デルタ名に従って 1 つのツリーが他の物より 前に処理されて不公平になるからです。

ctm_rmail のコマンドラインの引数には以下があります:

-l log
	stderr に出力する代わりに、 (コマンドラインのエラー以外の) エラー診断と情報メッセージ にタイムスタンプを付けた物がファイル log に書き込まれます。
-p piecedir
	デルタのかけらをこのディレクトリに集めます。 それぞれのかけらは 1 つのメールメッセージに対応します。 かけらは完全なデルタが出来上がると削除されます。 もし このフラグが指定されないと、入力ファイルは読まれませんが、 -b フラグが指定されていれば完成しているデルタは ctm を使って適用されるかもしれません。
-d deltadir
	このディレクトリ内の完成したデルタを集めます。デルタは、すべてのかけらが 揃っている時に 1 つ以上のかけらから組み立てられます。
-b basedir
	完成しているデルタを このソースツリーに適用します。このフラグが 指定されていない場合、デルタは格納されますが適用はされません。 ユーザは手動、または ctm_rmail を -p フラグ無しで使ってデルタを適用できます。 もしデルタが basedir の .ctm_status ファイルとマッチしない場合 (もしくは .ctm_status が存在しない場合) には、デルタは適用されません。
-D
	ctm による適用が成功した後でデルタを削除します。 ctm はデルタのフルセットからファイルの小グループを回復する機能を 持つので、このフラグを避けて (そしてすべてのデルタを取って) おくのが 良いでしょう。
-f
	fork して ctm でのデルタの適用をバックグラウンドで実行します。 これは sendmail から ctm_rmail を自動的に呼び出す場合に有効です。なぜなら ctm は終了までに、とても長い時間を要し、それによって他の人のメールを 遅らせる原因になり、理論的にはリモート側の sendmail のタイムアウトによるメールの不要な再送信や、 MH の slocal のようなメールフィルタによる ctm_rmail の強制終了を引き起こす可能性があるからです。 膨大な数のバックグラウンドの ctm プロセスでマシンに負荷がかかる心配はありません。同時に 2 つ以上の ctm が起動されないようにロックが行われているからです。
-u
	完成したデルタを適用する時に -u フラグを ctm コマンドに渡します。これによって作成、変更されたファイルの 変更時刻が CTM デルタの作成時刻にセットされます。
-v
	完成したデルタを適用する時に -v フラグを ctm コマンドに渡します。これによってより多くの情報出力が得られます。 すべての ctm からの出力は ctm_rmail のログファイルに記録されます。

引数のファイル (もし無ければ 標準入力 ) がデルタのかけらとしてスキャンされます。 1 つのファイルから複数のデルタのかけらを読む事ができるので、 メールドロップ全体を 1 回のコマンドでスキャンして処理できます。

ctm_rmail を並行に (異なる入力ファイルで) 複数回起動しても安全です。 sendmail がメールを非同期に配送した時にこのようなことが起こり得ます。 これは処理を順序通りに保つためにロックが行われているからです。

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

これは全部の ctm デルタを ~/ctm/deltas に置き、それらを /ctm 内のツリーに適用し、失敗したものは、すべてあなたの通常の メールボックスに落します。 ctm_incoming での PATH の操作は、このサンプルを取って来た ( FreeBSD でない) マシンで ctm_rmail から ctm(1) の実行を可能にするためのものです。

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

これらのメッセージは stderr かログファイルに出力されます。 ctm(1) からのメッセージも同様にここに現れます。 エラーメッセージは それ自身が説明的であるべきです。