特に悩んだのは、ディレクトリ階層が8レベルを超えた時に処理できないとい うことで、最初のうちはCD-Rの規格にこのような制限があることに気付かずに大 慌てだった。それに、そんなに深いディレクトリは作った覚えがなかったのだ。 覚えがなくても作っているものである。
ところで、ディレクトリのレベルが最高どれだけなのか、調べるにはどうすれ ばよいのだろう? 結局Perlを使ったが、何かエレガントなやり方がありそうな ものである。エレガントといえば、マスタリングソフトがエラーを出せるのだか ら、具体的にどれがダメなのか表示してくれたら話は早いのである。それがない から500MB程度あるファイルの山から問題のモノを探す羽目になるのだ。
---- list ---- # $max_level = 1;sub tree { local($dir, $level) = @_; local($d, $path, @dirlist);
$max_level = $level if $level > $max_level;
if (opendir(DIR, $dir)) { @dirlist = readdir(DIR); closedir(DIR);
foreach $d (@dirlist) { if ($d eq "." || $d eq "..") { next; } $path = "$dir\\$d"; print "$level $path\n"; if (-d $path) { &tree("$path", $level + 1); } } } }
&tree(".", 1); print "\nmax level = $max_level\n";
---- list end ----
後から購入したのはAdaptecの出しているEasy-CD Pro 95/NTというマスタリン グソフトである。ほいほいとボタンを押していくだけで、ちゃんとCD-Rが焼けて いる。今までの苦労は何だったのだろうか。弊害もある。すぐに「あのログはど のCD-Rに入れたっけ」という大混乱状態になってしまった。
CD-Rをがんがん焼くほどのデータがあるのかって? 最近結構なペースでハー ドディスクが侵食されている。一つは、やはりWWWの影響のようだ。ログじゃな くて、画像データが多いのだが、あまり細かい話を書いてしまうとアレなので、 ま、そんな感じである。もう一つの原因はWAVファイルだ。自作曲とかをそのま まWAVで録音すると、アッという間に数十MBのデータファイルがごろごろ、とい う状態になる。これはもちろんWAVではなくCD-DAの形式で焼くことになる。
私の場合は、128MBのMOをいくつかまとめてCD-Rに焼くという作業が多い。す ると、CD-RのトップディレクトリがM1,M2,…のような名前になる。最初、これを MO1,MO2,…という名前にしていたのだが、数字の「0」とアルファベットの「O」 が紛らわしくて、自分で指定した筈なのに何度もM01,M02,…と間違うので、結局M1 ,M2…という名前にすることにしたという経緯がある。
こうやってバックアップしたら、元のデータは消してもいいのだが、すぐ消さ ないでしばらく作業してしまうと、部分的に更新したファイルが散逸して話がや やこしい。この状態から、バックアップしたものだけ削除するにはどうすればよ いか。ディレクトリの下を全部比較して、同一ファイルだけ消すのである。手作 業だと無謀なら、再帰的に比較していくプログラムを作れば後はコンピュータの 仕事だ。
これで最近失敗したことがある。UNIX上で、再帰的にディレクトリを比較して、 内容まで一致したら削除するというスクリプトをPerlで書いた。アルゴリズムは 単純である。パス$p1とパス$p2に対して、両方ともファイルならば比較して一致 すればどちらかを消す。両方ともディレクトリならば、そこに移動してから、そ の下に存在する全てのファイルに対して再帰的に同様の処理を繰り返す。すると、 最後は一致していなかったファイルだけが残る。
これが全く穴だらけである。まず、両方とも同じ所にあるディレクトリを指し ているシンボリックリンクだったという大失敗をやった。ディレクトリだからそ の下に移って、比較を始める。比較しているのは実は同じファイルだから全部一 致して全部消えてしまう。処理が終わった時には予想以上にディスクが空いて大 ショック状態である。これはたまらないので、シンボリックリンクだったら移動 しないということにした。ここで安心したのか、ついコマンドを実行する時にcmpx d1 d1のようにパラメータを同じディレクトリにしてしまった。流石にこれはい くらでも一致する。
ところで、ファイルが完全に一致しても、生成時刻が異なる場合がある。cpコ マンドを単純に使った場合、日付がコピーした時点になるためらしい。CD-Rなら 消せないが、両方ともハードディスクにある場合、どちらのファイルを残すのが よいだろうか? オリジナルは古い方だから、古いものだけ残せばよいという考 え方もある。ログファイルのように毎日更新するファイルなら、ある時点のファ イルは途中経過であって、最新のものが最も完成に近い形だから、新しいものを 残せばよいという考え方もある。内容が完全一致するのだから、無駄な悩みかも しれないが、たまに困るのは2000年以降のファイルが何故だか既にあったりする のだ。
日付といえば、7月初めにfjニュースグループで珍事が発生した。fjは、NGMP( News Group Management Protocol)と呼ばれているルールに従って運営されてい る。これを改正する提案があって、異議申立て期間ぎりぎりに異議が出たのであ る。
fj管理委員会の行動はちょっち粗雑である。連絡ミスでなかなか新しい newsgroupが出来ないこともあったが、綴りを間違えてへんてこなnewsgroupを作 成して、それをcancelするコントロールがまた間違っていたりして。これが「ご めん」で済むのがfjのいい所で、NIFTY SERVEだったらSYSOPの首が飛ぶかもしれ ない。
fj.news.usageの盛況ぶりを見る限り、「大変高度な研究材料の一つとして極 めて興味深い」という点で、うまく行っているような気がしないこともない。テ スト投稿あり、宣伝あり。例の小学生殺人事件の容疑者の実名が流れるし、顔写 真の画像データは投稿されるし、確かにあのような場はNIFTY SERVEのフォーラ ムには存在し得ないだろう。まあそれはともかくとして、珍事というのはこうで ある。管理委員の説明では、異議のe-mailが送信された時刻は「Date: Wed, 2 Jul 1997 23:58:19 +0900」で、委員が受け取ったのは「Date: Thu, 3 Jul 1997 00 :01:03 +0900」。NGMPのCFA(異議がなければ合意があったとする)期間は、記事 の一部を紹介しておく。
---- fj.news.policy に投稿された CFA ---- > CFA期間: 1997.6.18-1997.7.2 > > NGMPの本改訂案への変更に異議のある方は、上記期間内に > kuno@gssm.otsuka.tsukuba.ac.jp宛に > > Objection [CFA] Substitute NGMP with Kuno's Proposal #19なお、このCFAが出た時刻は「Date: 18 Jun 1997 07:05:40 GMT」である。こ れが重要なポイントなので頭に入れておいてください。> というSubject: を持つメールをお送りくださるとともに、 > fj.news.policyにも同内容をご投稿ください(私がいずれか一方でも認 > 識すれば異議は成立したものとします)。異議のないまま期間が経過し > た場合、NGMPの本改訂案への変更が実現することになります。 (略)
Subject: [CFA] Substitute NGMP with Kuno's Proposal #19 Message-ID: <5o81c4$qr@utogw.gssm.otsuka.tsukuba.ac.jp>
--------
どこが珍事? 異議のe-mailが送信された時刻も受け取った時刻も+0900と書い てある。これは、標準時より9時間多い値で表現するという意味だ。すなわち、 異議のe-mailが出た時刻は2 Jul 1997 14:58:19 UTC、委員がこれを受け取った のは2 Jul 1997 15:01:03 UTCということになる。ということは、余裕で期間内 に異議が認識されているではないのか?いやいや、なぜUTCなの? fjの時刻はJST で表現するに決まっているじゃないですか。
それって、どこに?
これが探したのだが見つからないのだ。つまり「fjの投票における日付の計算 はJSTを基準とする」のような規則がないのである。もちろん「fjって日本じゃ ん、日本だったらJSTに決まってるじゃん?」という安易な発想もあるが、間違っ てもfj.news.usageでそんな事を書かない方がいいと思う。ともあれ、「fjはfrom japanなんだから日本の時刻を基準にするのに決まっている」という主張も現実 的な説得力がないわけではない。
それにしてもNGMPの中に、あるいはCFAの中に「JSTを基準にする」のような一 文があれば済む話なのに、そのような記述がない。だから、基準は曖昧か、もし くはJSTでいいじゃないか、という所に落ち着きそうなものだが、ここでCFAが出 た時刻を思い出して欲しい。「Date: 18 Jun 1997 07:05:40 GMT」なのである。 「Date: 18 Jun 1997 16:05:40 +0900」ではないのだ。これが珍事なのである。 CFAを出した人は何を考えて+0900ではなく、わざわざGMTで表記した18日に出し たのか?多分ニュース投稿のプログラムの設定がたまたまそうなっていただけで、 実は何も考えていないのではないかと思うのだが、いずれにしても、結局、fj管 理委員会はGMTで表現された投稿時刻を持つ記事の中の期間をJSTと解釈して、指 定期間内に異議がなかったと結論し、このCFAを成立と判断した。
提案者が第三者ならともかく、管理委員による提案を、管理委員の都合のよい 結論でまとめてしまうというのは、もしNIFTY SERVEでこういうことをやったら、 fjで思う存分叩かれそうな気がしてどうも恐ろしい。
(フィンローダ ニフティサーブ FPROG SYSOP)