[FreeBSD-users-jp 96602] dump(8)の生成物の verify

[Koh-ichi Ito]

stay home の夏休みだからか、ここのところ活況ですね。ぼくも困りごとができ 
ちゃいまして…

Bugzilla の Bug 244470 - /sbin/dump crashes on larger filesystem を踏ん 
じゃいました。レポートされた Stefan Thumer さんが Comment 1 で、r331095 
のソースをコンパイルしたら復旧した、って書いていらっしゃるので、ぼくも 
やってみたんですが、ぼくの 12.1-RELEASE-p8 では

   DUMP: estimated 295925594 tape blocks.
   DUMP: SIGSEGV: ABORTING!
   DUMP:   DUMP: SIGSEGV: ABORTING!
SIGSEGV: ABORTING!
   DUMP:   DUMP: SIGSEGV: ABORTING!
SIGSEGV: ABORTING!
Segmentation fault (core dumped)

と却って悪い結果になり、dump.core なんていう印象的な名前のファイルまで生 
成してくれちゃったので、root で走るプロセスだしマズいよなぁ…と思いながら 
もバックアップがとれないのは致命的なので、dump は読む一方で、ターゲット 
のファイルシステムをブッ壊すことはきっとなかろう、と判断し、r339434 の 
ソースを checkout してきて、traverse.c の問題の assert()の箇所を #if 0 
〜 #endif ですっ飛ばして make てみました。できたバイナリは、一応最後まで 
dump した素振りを見せています。

で、ここからが識者の皆様に教えを請いたい本題なんですけど、このいかさまバ 
イナリが生成したファイルをベリファイしたいと思っています。ですが、 
restore(8)の -t オプションは

	The names of the specified files are listed ...

と書いてあるし所要時間から考えても、インデックス的な部分を舐めているだけ 
でデータ本体は検証していないように思います。

何かうまいベリファイの方法があれば、教えていただけないでしょうか?

＃ 別ファイルシステムに restore r して find -exec cmp {}\; ってのはナシ 
でお願いします。

＃ 事象を認知した朝、長年うちの本棚を占拠していた2001年〜2002年のユニマ 
ガを資源ゴミに出した祟りではないかと、おののいています。お盆だし…

どうぞよろしくおねがいします。
-- 
kkdlabs.jp, featuring Koh-ichi Ito as just another DNS freak in town.