[ 98/12/15]
● ATOK11 と Microsoft Word 6 の Mac OS 8.5 での問題：回避法
ある方からお教えいただいた． Mac OS 8.5 において，ATOK11 を日本語入力変換プログラムとして Microsoft Word 6 を起動するとマウスが操作を受け付けなくなる問題について， Microsoft 社はサポート技術情報として
[M_WD6]OS8.5 上で ATOK11 使用時にマウスが使用できないというページを設けた．
それによると， Word 6 は Mac OS 8.5 で動作保証していないとしながらも，次のような回避法が書かれている．
-
回避方法
1．キーボードの command + space で入力状態を US モードに変更する．
2． "ツール" メニューの "オプション" を選択．
3． "編集" タブをクリックして選択し， "未確定入力文字列を文書に挿入モードで入力する" チェック ボックスをオフにする．
なお，これに伴い，
ジャストシステムのページが更新されている．
● Norton Disk Doctor ： レコードキー重複報告修復でのハードディスククラッシュ（継続）
98/12/9 項目の Norton Disk Doctor 4.0.1 がレコードキー重複という報告をし修復させるとハードディスクボリュームが認識できなくなる問題について，何人かの方から同様の障害のご確認をいただいている．
Hayashi 氏はフォーマットを余儀なくされ，フォーマット後にバックアップを戻すと同じように Norton で問題報告されるようになる．（私も同じようになった．）氏が調べたところバックアップしていたシステムファイルの何かが壊れていたようで，システムの上書きインストールでは改善されなかったが新規インストールで症状が全く出なくなった．
Hanabusa 氏は Norton に修復させて障害が発生し，ハードディスクがマウントされなくなった．氏は TechTool Pro を購入して使用したところマウントすることができた．しかし，ディスクの使用量など挙動がおかしいため重要ファイルをバックアップ後， Norton，TechTool Pro， Disk First Aid を繰り返し何度も使用したところ，最後にはどのツールでもエラーが出なくなった．
さて，私の場合だが，エラーの報告は無視しても気になるものだし， Disk Doctor が事実上使えなくなるのは残念なので，原因が分かるかどうかまた試してみた． Hayashi 氏の場合のようなファイルに問題がないか，ハードディスクボリューム第１階層のフォルダをひとつづづ消去しながらいちいち Disk Doctor をかけて検証していったのだが，不可視ファイルを含め，全てのファイル，フォルダを削除してもエラーを報告し続けた．
そのため，三度目となるのだが，（前回報告時に確認のため二度繰り返した） Norton による修復をさせたところ，またもディスクボリュームはマウントできなくなった． Hanabusa 氏が御指摘のように TechTool Pro 2 を使用すると，ボリューム自体はマウントされるようになるまで修復されるのであるが，ボリュームの内容は回復不能でめちゃくちゃの状態になっている．
三たびそのボリュームを初期化し直し，バックアップファイルをフォルダ単位で一つ戻しては Norton をかけるという作業を繰り返した．その結果，今回は異常が発生しないまま最後まで終わってしまった．
ということで，現在は何も問題はなくなってしまい，原因は不明となった．ただ，今回は前二回と異なる操作を行っている．それはファイルを戻しながらの Norton の診断時に出るカタログ B ツリーのディスク領域浪費報告について，これまでは無視していたのを修復させながら作業を行ったのである．浪費報告とレコードキー重複報告に何らかの関連性があるのだろうか．
参照：
98/11/15 項目「 Norton Disk Doctor 4.01： Mac OS 8.1 での HFS + ディスクエラー報告」
● Mac OS 8.5 ：デスクトップへのボリュームマウント順と変更法
Apple Tech Info Library に Mac OS 8.5 からのデスクトップのハードディスクなどのマウント順の解説と AppleScript による変更法が公開された．以下で紹介する AppleScript には追加の Script も掲載されていて，それにより，マウント順をたびたび変更するユーザに対応している．追加の Script 等詳しい情報はオリジナルページを参照願いたい．なお，マウント順の変更については同様の機能を持つ
RestorePosition Ver1.0b1 が公開中である．
TIL: 30871 : Mac OS 8.5: Disk Positioning on Desktop after Startup
Mac OS 8.5 のデスクトップのパーティション表示順序
-
1．起動パーティション
2．非リムーバブルパーティション
3．リムーバブルパーティション（Zip, CD-ROM ほか）
4．マウントされたサーバ
起動パーティション以外はそれらのグループ内で各パーティションでの使用量順に表示される．従って，使用量の変化によっては順序が変わることがある．
マウント順は次の Apple Script を用いることで変更できる．（起動項目フォルダに入れておく）
-
--Begin AppleScript
property DiskNames : {}
property DiskLocations : {}
if DiskNames is {} then -- first time, initialize
--capture current values to persistent property variables
tell application "Finder"
set DiskNames to the name of every disk of the desktop
set DiskLocations to the position of every disk of the desktop
end tell
else
--set positions from retained values
repeat with i from 1 to number of DiskNames
set DiskName to item i of DiskNames
tell application "Finder"
if disk DiskName of desktop exists then --present now?
set the position of disk DiskName of desktop to item i of DiskLocations
end if
end tell
end repeat
end if
--End AppleScript
●よもやま（その二）： Sherlock 索引
98/12/13 項目「よもやま（その一）： HFS + でのパーティション」の続きである．
Sherlock 専用パーティションをようやく作成することができた．ここ数日は Sherlock 索引の作成にマシンの能力がほとんど割り当てられていた．以前にも，「よもやま」として記載した Sherlock だが，その後，日本語トークナイザの機能制限から，数字（日付なども）および 2 文字以下の英単語は調べられないことやスラッシュやピリオドがある場合は別の単語として扱われることが明らかになった．
参照：
98/11/9 項目「よもやま： Sherlock の内容検索ほか」
98/11/30 項目「 Engineer DIRECT」の日本語トークナイザの項
「索引不十分」
私がこれまで使用して気づいた点が他にも出てきた．
-
・索引化されないテキストデータがある？
・索引作成は一回では不十分ではないか？
最初から不審に思っていたのだが，ある種のテキストデータが索引化されていないのか，検索でヒットしないのである．例えば，私が作成して公開しているこれらページの HTML ファイルがほとんどヒットしない．私はこれらページを Jedit で作成，保存しているのであるが， Jedit 書類が索引化されないわけでもないようであるし， HTML 書類が索引化されないわけでもないので，原因がよく分からない．
ひょっとしてとも思う点は， Sherlock にそれらのファイルが索引化されないわけではなく，内容検索でのヒットが 100 項目までという上限があるためかもしれない．
（対象ファイルが絞られている場合は Jedit のマルチファイル検索の方が便利なので，もともと私は Sherlock を私のページのファイルの検索に使用していないのであるが）
Adobe Acrobat の PDF 書類は索引化されない． Apple が PCF の形で多くの技術資料を公開していることからも，以前書いた HTML ファイルがタグを索引化してしまう点と並んで改善を望みたい． Microsoft Word 書類などバイナリファイルの索引化も将来の課題だろう．
また，作成された索引は一回作成しただけでは不十分ではないのだろうか．というのは，一回目に作成した索引の容量が少ないのではないかと思って，更新をすると倍近くの容量になったからである．このことが分かった結果，私は一回目の作成が終了してもそのまま続けて 2 度索引の更新をしなければ気が済まなくなった．
「索引のバックアップ」
索引データは簡単にバックアップすることができない．バックアップするためにはボリュームをディスクイメージとして保存しなければならないだろう．試みに不可視ファイルを可視化してバックアップして，それを初期化したディスクに戻して不可視にしたところ，索引が壊れているといわれて使えなかった．
場合によっては作成するためにコンピュータの処理能力のほとんどを何日もそのために振り向けなければならないようなものを通常の方法でバックアップできないというのは改善されるべきではなかろうか．
「索引から除外するファイル指定」
このことは検索フォルダを開くと誰でも分かることだと思って項目にしてこなかったのだが，案外知られていないようだ．
索引化を除外するファイルは機能拡張フォルダの "検索" フォルダにある "StopExts" と "StopTypes" というファイルによってそれぞれ拡張子とファイルタイプが指定されている．これらのファイルはエディタで開くことができるので，追加したいファイルの種類がある場合，ファイルタイプなどをこれらに追加し，クリエータを変更しないようにして保存すればよい．
私は Sherlock がどうも和文 ATM のファイルを索引化している可能性があるように思えたので "ATMJ" と，先の "StopTypes" ファイルに記載のない "mlts" のファイルタイプ（ CCL ファイル）を付け加えている．
「その他」
・索引作成中の状態を見るには，プログレスバー以外に方法がある． Sherlock の「ボリュームの索引作成」ウィンドウをいったん閉じて，再び「ボリュームの索引作成」を表示させると，索引の最新のデータ容量と保存日時を知るができる．
・索引作成を中断してもう一度行うと更新となり最初から走査し直すため，索引を作成し始めたら索引作成終了までコンピュータは点けっぱなしにする．スリープは支障がない．
・索引作成中はできるだけマシンでの他の作業を避ける．私の場合，索引作成中に同時に何かの作業をしていると，バックグラウンドで Eudora Pro のサーバへのアクセスがあったときや，ファイル共有が動作するときに何度かフリーズした．その度に最初から索引を更新し直さなければならなくなった．
索引作成にはコンピュータの能力の多くが要求される．初期設定で索引作成を速く設定している場合，そのコンピュータでの作業には支障が出る．かといって，索引作成を遅くしているといつまでたっても索引はできない．
・索引作成中にフリーズなどで再起動すると， OS の使用メモリが増大したままとなる． RAM ディスク等に索引作成して正常に索引作成を終了させることでメモリを正常に戻すことができる．
（参照： 98/12/3 項目「 Mac OS 8.5 でのメモリ増大： Sherlock/日本語解析エンジンとの関連？」）
(C) Akiyama Satoru
