HFS+の問題

本ページは、過去に取り上げたHFS+関連の記事をまとめたものです。
内容は当時のものですので、ご注意下さい。

[98/02/05]

• Disk Tools PPCについて
  
  Mac OS 8.1(US)と同時に配布されたDisk Tools PPC（起動FD）を使用してMacを起動すると、HFS+形式のハードディスクのボリューム名やファイル名が見えなくなっちゃいませんか？
  
  何か変だなとは思っていたのですが、Primary scriptがRomanのときに作成したHFS+ボリュームは、Disk Tools PPCで起動してもボリューム名やファイル名が見えることがわかりました。
  
  以前にも書きましたが、私はMac OS 8.1(US)のPrimary scriptをJapaneseに切り替えて使用しています。この状態で作成したHFS+ボリュームを、Disk Tools PPCで起動して参照すると、ボリューム名やファイル名が見えなくなってしまうようです。
  
  AppleのTech Info Libraryの記事を調べたところ、記事番号30345「Mac OS 8.1:About Mac OS 8.1 Update」の「Mac OS Extended and Language Kits」の項目に次のようなことが書いてありました。
  
  
  Mac OS 8.1と共に供給されるDisk Tools PPCは、primary scriptと英語での使用を意図している。Language Kit（secondary script）を使用する場合はMac OS 8.1 CDを使用しなければならない。Disk Tools PPC FDを使用してコンピュータを起動すると、secondary scriptで作成したボリューム名やファイル名はごちゃごちゃになるか失われる。それらを変更しようと試みると、ファイルを失うかもしれない。
  
  

  Primary scriptを変更している場合も、Language Kitの場合と同様の問題があると思われます。
  
  US版システムのPrimary scriptを変更したり、Language Kitを使用して日本語環境で使用している方も多いと思います。現時点ではMac OS 8.1のCD-ROMは入手できませんので、HFS+形式のボリュームを使用している方はDisk Tools PPCの使用には十分な注意が必要だと思います。
  
  なお、訳には自信がありませんのでなるべく原文をお読み下さい。訳の誤りがありましたらご指摘ください。

[98/02/18]

• [注意] DiskTools PPCについて
  
  付録CD-ROMにMac OS 8.1アップデータを収録したMacPeople3/1号では、誌面でも「徹底解説」として特集しているのですが、「HFSプラスはこう作る」という記事（P.108）では、外付けハードディスクなどを持っていない場合、「ディスクツールズを使おう（英語版だが問題ない）。」と書かれています。
  
  しかし、本ページの2/5の記事でも書いたように、Disk Tools PPCはPrimary scriptがRomanの場合の使用を想定しており、Disk Tools PPCでコンピュータを起動してRoman以外のscript（日本語システムの場合も含む）で作成されたHFS+ボリュームのファイル操作を行うと、最悪の場合、ファイルを消失することになります。
  
  また、Mac OS 8.1(J)アップデータ中の「Mac OS 拡張フォーマットについて」にも書かれていることですが、「日本語版以外のシステムで起動している場合、HFS+フォーマットのディスクにファイル名を正しくコピーできない」場合があります。
  
  これは、HFS+ではファイル名をUnicodeで管理しているため、HFSから HFS+へファイルをコピーする場合にはファイル名がUnicodeに変換されるのですが、そのファイル名がどの言語で作成されたかは分からないため、起動しているシステムに依存した言語に変換されてしまうためです。
  
  Disk Tools PPCで起動するということは、つまりRoman scriptの状態で起動することになりますので、注意が必要です。
  
  ご存知の通り、Mac OSはたいへん国際化の進んだシステムであり、US版システムであってもLanguage Kitやscriptの変更等で、比較的簡単に日本語化が可能なんですが、HFS+に関しては、ボリュームを作成したscriptと起動中のscriptが異なると様々な問題を引き起こす可能性があります。
  
  全てをUnicodeで管理するようになれば、話は簡単になるのかもしれませんが、現在は過渡的な状況ですので、ある程度は仕方のないことなのかもしれません。
  
  
• HFS+とUnicode
  
  HFS+関連でもう一つ。Mac OSでは、ファイル名の大文字／小文字を区別しませんので、従来のHFSディスクでは、たとえば「診」と「色」という名称のファイルを同一の場所に作成することができませんでした。
  
  これは、Shift-JISコードで「診」は「9066」、「色」は「9046」なんですが、「66」は小文字の「f」、「46」は大文字の「F」と同じ値であるため、Mac OSはこの2つのファイルを同一名称と判断してしまうからです。
  
  しかし、前述のようにHFS+では、ファイル名をUnicodeで管理するため、この2つのファイルを異なる名称と判断します。
  
  

  HFS+では、「色」と「診」という名称のファイルを同一フォルダに作成できる。しかし、HFSでは「診」という名称のファイルがすでに存在する場合、「色」という名称のファイルを作成することができない。

  
  このため、たとえばHFS+ボリュームからHFSボリュームへファイルをコピーする場合、HFS+では異なる名称のファイルと認識されていたファイルが同一名称と認識され、予期せぬ結果（ファイルの上書きなど）を招く可能性がありますので、ご注意を。

[98/03/18]

• MacPeople誌の記事のこと
  
  MacPeople 4/1号にもSteve Wozniak氏のインタビュー記事が掲載されていました。
  
  ここで注目すべき点（？）は、個人的にはどんなコンピュータを使っているかという質問に対してWoz氏は「20周年記念マックも数台持っています。」と答えていることです！
  （いいな〜）
  
  同誌には、ハイパーカード等の開発者で、現在は写真家のBill Atkinson氏のインタビュー記事も掲載されていました。
  
  ところで、MacPeople誌といえば、本ページの2月18日の記事でも触れたように、3/1号の記事中に「英語版のDiskTools PPCを使用しても問題ない」との記述がありました。
  
  この件に関する「お詫びと訂正」が、4/1号「HFSプラスは入れるべきか？」の記事中に掲載されています。（P.101）
  
  どうでもいいけど、この文章、私が送った指摘メールの文面ほとんどそのまま（笑）。
  
  それはともかく、重要なことですので、本ページの2月18日の記事内容を再掲しておきます。
  
  

  [注意] DiskTools PPCについて （中略） 本ページの2/5の記事でも書いたように、Disk Tools PPCはPrimary scriptがRomanの場合の使用を想定しており、Disk Tools PPCでコンピュータを起動してRoman以外のscript（日本語システムの場合も含む）で作成されたHFS+ボリュームのファイル操作を行うと、最悪の場合、ファイルを消失することになります。

  
  HFS+ボリュームを使用されている方は、ご注意ください。すでにMac OS 8.1(J)のCD-ROMも入手できるようなので、これを利用されたほうが良いでしょう。

[98/03/24]

• 【注意】HFS+の互換性について
  
  3月21日付けのMacintoshトラブルニュースさんの記事に、「英語システムで作成したHFS+にインストールした日本語システムから起動しようとすると、文字化けしたアラートが表示されて起動できない」という問題が掲載されていました。
  
  私は、この組み合せは検証していなかったため、早速確認してみることにしました。
  
  確認は、内蔵HDを4つのパーティション（G3-1〜G3-4）に分割したG3 DT/233で行いました。
  
  【検証１】
  
  まず、以下の手順で確認を行いました。
  
  (1) Mac OS 8.1(US) CD-ROMから起動。
  (2) 一つのパーティション（G3-4）をFinder上からHFS+で初期化。
  (3) 「起動ディスク」コントロールパネルで、Mac OS 8.1(J)のパーティション（G3-1：HFS）を指定して再起動。
  (4) G3-1（HFS）のシステムフォルダをG3-4（HFS+）へドラッグしてコピー。
  (5) 「起動ディスク」コントロールパネルで、G3-4を指定して再起動。
  
  これは問題なく起動しました。
  
  【検証２】
  
  次に、以下の手順で確認を行いました。
  
  (1) Mac OS 8.1(US) CD-ROMから起動。
  (2) 一つのパーティション（G3-4）をFinder上からHFS+で初期化。
  (3) G3-1（HFS）のシステムフォルダ（文字化けしている）をG3-4（HFS+）へドラッグしてコピー。
  (4) 「起動ディスク」コントロールパネルで、G3-4を指定して再起動。
  
  なんと、今度は文字化けしたアラート（AppearanceLibと書かれているのが読めます）が出て、起動できません！
  
  念の為、どちらも複数回の確認を行いましたが、同じ結果となりました。
  
  どちらも「USシステムで初期化したHFS+ボリュームの日本語システム」から起動しています。両者の違いは「日本語システムのコピーをUSシステム／日本語システムのどちらで行ったか」のみです。
  
  「検証２」と同じ手順をHFSボリュームに対して行うと、問題なく起動します。
  
  つまり、「USシステム上で、日本語のシステムフォルダをHFS→HFS+へコピーする」ことに問題があるようです。
  
  本ページの2月18日の記事でも書きましたが、Mac OS 8.1(J)の「Mac OS 拡張フォーマットについて」には「日本語版以外のシステムで起動している場合、HFS+フォーマットのディスクにファイル名を正しくコピーできない」場合があると記載されています。
  
  これは、HFS+ではファイル名をUnicodeで管理しているため、HFSから HFS+へファイルをコピーする場合にはファイル名がUnicodeに変換されるのですが、そのファイル名がどの言語で作成されたかは分からないため、起動しているシステムに依存した言語に変換されてしまうためです。
  
  ここからは推測にすぎないのですが、USシステム上で日本語のシステムフォルダをHFS+へコピーする際に、名称が不正になったファイル／フォルダがあったのでしょう。
  
  そして、基本的にはシステム関連のファイルやフォルダの名称に依存した処理を行ってはならないことになっていますが、起動時の何かの処理が名称に依存した処理を行っていた。
  
  そのため、必要なファイル／フォルダを見つけることができす、起動できなくなってしまった。
  
  こういうことではないでしょうか？
  
  素人の推測ですから、外していた場合はご容赦くださいね。
  （私、一応本業はプログラマですが、Macは専門外ですので。）
  
  トラブルニュースの秋山氏が経験された事態が、本件と同件かどうかは不明ですが、同様の問題はシステムフォルダ以外でも発生する可能性があります。
  
  起動不可能にはならなくても、ファイル／フォルダの名称が不正になり、他のトラブルを引き起こす可能性がありますので、HFS+をご利用の方は十分にご注意下さい。

[98/03/25]

• HFS+の互換性について（補足）
  
  昨日の記事で、説明不足の点がありましたので補足しておきます。
  
  問題が発生するのは「日本語以外のシステムで起動している場合」と書きましたが、より正確に言うと「Japanese以外のスクリプトで起動している場合」です。
  
  これは、日本語システムで日本語関連の機能拡張書類をオフにして起動した場合も含まれます。
  （スクリプトがRomanになるため）
  
  また、US版システムのスクリプトをJapaneseに変更して使用されている場合、スクリプトを変更したシステムと、素のUS版システム（CD-ROM等からの起動）の間で同様の問題が発生する可能性があります。
  
  いたずらに不安を煽るつもりはありませんが、日本語システムのみ、あるいはUSシステムのみをお使いの場合でも、この問題が発生する可能性がありますので、HFS+をご利用される際には、十分にご注意ください。

[98/03/26]

• スクリプトの話
  
  HFS+の互換性につきましては、現在も調査中です（後述します）。
  
  その前に、WAOさんが期待しているようなので（笑）、（プライマリ）スクリプトのことを少し説明しておきます。
  
  プライマリ スクリプトとは、大雑把に言うとシステムの「国籍」みたいなものです。
  
  通常、日本語システムのプライマリ スクリプトは「Japanese」、USシステムは「Roman」です。
  （なんで「米国」の国籍が「ローマ」なんだ？というツッコミは、とりあえずおいといてください）
  
  たとえば、JLK（Japanese Language Kit）をインストールしたUSシステムは「日本語が使用できるUSシステム」ですが、Script Switcher等を利用してプライマリ スクリプトを「Japanese」に切り替えると「メニューが英語の日本語システム」という扱いになります。
  
  「Japanese」や「Korean」のようないわゆる2バイト圏のスクリプトを使用するためには「WorldScript II」が必要です。
  
  Shiftキーを押して機能拡張書類を読み込まずに起動した場合、当然「WorldScript II」も読み込まれませんので、プライマリ スクリプトはデフォルト（初期値）の「Roman」になります。
  
  余談ですが、一部のソフトではプライマリ スクリプトを判定して、特定の言語版システム上でないと動作しないものがあります。
  
  たとえば、「AfterDark 4.0.3(US)」のアップデータは日本語システム上では使用できませんでしたが、機能拡張書類を読み込まずに起動すると使用可能になります。
  
  本題に戻ります。
  
  本ページで取り上げているように、ＨＦＳ+では異なるスクリプト間でのコピーで問題が発生する可能性が高いと思われます。
  
  通常は、スクリプトのことを気にされてない方も多いと思いますが、たとえば機能拡張書類のコンフリクトが発生した時、Shiftキーを押して起動して、HFSボリュームのバックアップをHFS+ボリュームにコピーしたりすると、この条件に該当してしまいますので、ご注意ください。
  
  
• 文字化けアラートの件
  
  前述しましたように、HFS+の互換性問題につきましては現在も調査中ですが、とりあえず文字化けアラートの内容が判明しましたのでお知らせしておきます。
  
  文字化けしたアラートを解読（笑）しましたところ、「システムライブラリのAppearanceLibが見つからないのでFinderが起動できない」と書かれているようです。
  
  これは、たとえば機能拡張フォルダから「Appearance機能拡張」を外して起動した場合等に表示されるアラートです。
  
  また、文字化けしていることから日本語関連の書類も見つかっていないことが推測されます。機能拡張フォルダ自体が見つからないのかもしれません。
  
  根本的な原因は継続して調査中ですが、何か分かりましたらまたお知らせしたいと思います。
  （分からないかもしれませんが）

[98/03/27]

• 続・HFS+の互換性について
  
  本当はもう少しはっきりとしたことが判明してからお知らせしたかったのですが、調査に行き詰まってしまってます．．．。
  
  「Romanスクリプトで起動し、HFS+ボリュームにコピーしたシステムフォルダ」の中に「名前の無いフォルダ」が作成されていることが分かりました。
  
  このフォルダを開くと、初期設定ファイルが2個あるだけのように見えます。
  
  

  
  なぜか片方のファイルには名前がないのですが、さらに不思議なことに、このフォルダの「情報を見る」と、66個の項目を含んでいると表示されます。
  
  この項目数と容量は、システムフォルダと同じです。
  

  
  他のいくつかの状況（FinderPopのContents表示等）から、この「名前の無いフォルダ」は「システムフォルダ自体」を差していると推測されます。
  （つまり、システムフォルダが無限ループしている）
  
  ディスクの管理情報か何かが破壊されているような気がするのですが、Disk First Aidで検証してもエラーは発見できません。
  （Norton UtilitiesはHFS+未対応のため使用できません）
  
  この「名前のないフォルダ」は、「Romanスクリプトで起動し、システムフォルダをHFS+へコピー」した段階では作成されません。
  
  そのHFS+ボリュームからの起動を試みて、文字化けアラートが表示された後、別のボリュームから起動して当該HFS+ボリュームを参照すると、作成されています。
  
  当該HFS+ボリュームから起動しようとした際に、管理情報が破壊されるのかもしれません。
  
  以前にも書きましたように、Mac OS 8.1(J)のRead Meファイルには、日本語以外のシステムで起動した際にHFS+のボリュームへファイルを正しくコピーすることができない場合があると記載されていますが、ファイルの名前が不正になるだけで内容には問題がないとしか記載されていません。
  
  関連は不明ですが、異なるスクリプト間でのコピーが、ファイル名の問題とは別の問題を起こしているのかもしれません。
  
  とりあえず、調査を続行してみます。
  
  HFS+について、何かお気づきのことがありましたら、お知らせください。

[98/03/30]

• HFS+の互換性（継続）
  
  HFS+の互換性問題につきましては、現在も継続して調査中です。
  
  「USシステム（Romanスクリプト）上で、日本語システムをHFS→HFS+へコピー」すると起動できなくなるという件ですが、Systemファイルのリソースを編集し、「機能拡張」フォルダの名称だけを英字（Extensions）に変更して検証してみたところ、問題なく起動できることが分かりました。
  
  やはり、Japanese以外のスクリプト上で、日本語の名称のファイル／フォルダをHFS+へコピーすることは問題があるようです。
  
  今回の件で、起動できなくなった直接の原因は、「機能拡張」フォルダの名称が日本語であったため、Romanスクリプト上でのHFS+へのコピーでフォルダ名が不正となり、その結果起動時に「機能拡張」フォルダを見つけることができなかったためではないかと推測されます。
  
  引き続き、HFS+に関する情報もお待ちしています。

[98/03/31]

• HFS+の互換性（継続）
  
  市川さんから「消去できない初期設定」についての情報を頂きました。
  ありがとうございます。
  
  

  私の状態は、３／２７にPoseidonさんのホームページ上に掲載されているのとまったく同じでした。 それらのファイルをどういじっても解決しなかったため、私はフォーマットし、（性懲りも無くHFS＋で（＾＾；））現在は何とか動いてます。 私はトラブルの為、Shiftキーを押したまま、機能拡張を読み込まずに起動したために、そういった状態になったのではないかと思われます。 一度そうなってしまったら、FileBuddyやResEditを使用しても、ファイルの属性も変更できないうえ、一時的に移動して削除などといったこともできず、何をやってもダメ。 Untoucheableな存在になってしまって、かなり困りました。 正しい環境でDeskTopの再構築などすれば直るのかどうか疑問に思えた為、私はInitializeからやり直してしまいました。

  
  書いていませんでしたが、私の環境で発生した「名前のないフォルダ」も削除などができませんでした（ゴミ箱へドラッグするとFinderが落ち、デスクトップへドラッグすると「タイプ-110のエラー」になる）。
  
  やはり、Japanese以外のスクリプト上で日本語のファイルを操作するのは危険なようですね。
  
  コンフリクト等の問題が発生した時、Shiftキーを押したままの起動を行うのはごく当たり前の対処法ですが、それが別の新たな問題を起こす原因となってしまうのであれば困ったことです。
  
  また、Disk First Aidではエラーが発見できないのですが、何らかの異常があることは間違いないと思われますので、Norton Utilitiesに早くHFS+に完全対応してもらいたいと思います。
  （Nortonでも問題が発見できるとは限りませんが）
  
  どこに異常があるのかは分かりませんが、以前にも書きましたようにディスクの管理情報が壊れている可能性もありますので、そのまま使用を続けると、被害が拡大する可能性もないとは言い切れません。
  
  このような現象が発生した場合は、重要なデータを別のディスクに退避し、ディスクの初期化を行った方が良いでしょうね。
  
  引き続き、情報をお待ちしています。

[98/03/31] (2)

• HFS+とUnicodeとプライマリ スクリプト
  
  この記事は、本来4月1日分の記事にする予定でしたが、冗談だと思われても困るので（笑）、31日の2回目の更新とします。
  （冗談自体は嫌いではありませんので念の為）
  
  継続してお伝えしている「Romanスクリプト上で日本語のシステムフォルダをHFS→HFS+にコピーすると起動できなくなる」という件ですが、ようやく原因が見えてきたような気がします。
  
  30日の記事に書きましたように、Systemのリソースを編集し、「機能拡張」フォルダの名称だけを英字（Extensions）に変更して検証すると、問題なく起動します。
  
  また、一旦起動できなくなった後、別ボリュームの日本語システムで起動し、「機能拡張」フォルダの名称を書き直す（名前をクリックしてクリアした後、もう一度「機能拡張」と入力する）と、そのシステムフォルダから起動可能になることが分かりました。
  
  これらのことから推測されることを以下の手順で検証してみました。
  
  【検証手順】
  
  

  (1) Japaneseスクリプトで起動し、 HFSボリュームに「テスト」と「test」の2個のファイルを作成。
  (2) Romanスクリプトで再起動し、上記のファイルをHFS+ボリュームへコピーする。
  (3) Japaneseスクリプトで再起動し、Finderの「編集」-「複製」で「テスト」と「test」をそれぞれ複製する。
  (4) 「testのコピー」の名前を「test」に変更しようとすると、当然「すでにある」というアラートが出て変更できない。
  (5) 次に、「テストのコピー」の名前を「テスト」に変更すると、アラートは出ず、「テスト」という同じ名前のファイルが同一の場所に共存する。
  (6) 「ファイル検索」で「名前がテストの項目」を検索。確かに同じ名前であることが分かる。

  
  【推測されること】
  
  これは、「テスト」はRomanスクリプト上でと文字化けしますので、上記（２）の手順でHFS+へコピーされたファイルの名称はUnicodeのに変換されてカタログに記録されていて、手順(5)でJapaneseスクリプト上で変更した後の名前は、そのままUnicodeの「テスト」に変換されてカタログに記録されていることが推測されます。
  
  つまり、どちらも「テスト」に見えていますが、カタログ上は「テスト」と「」という別の名称のファイルであるので、同一の場所に共存できるのではないでしょうか？
  
  「ファイル検索」は、カタログに記録されたUnicodeのファイル名ではなく、Shift-JISコードに変更された後の名前で検索しているので、どちらも同じ名前と判断するのでしょう。
  
  Romanスクリプト上でHFS+にコピーしたシステムフォルダから起動できない理由も同様と考えられます。
  
  Romanスクリプト上で「機能拡張」が文字化けした状態でカタログに記録されたため、起動プロセスで「機能拡張」という名称のフォルダが見つからず、その結果「Appearance機能拡張（AppearanceLib）」が見つからなかったため、起動できなかったものと推測されます。
  
  また、Nagisa's Land!さんが、「同じ名前の初期設定ファイルが2つ存在する」という現象を報告されていましたが、HFS+上の日本語名の初期設定ファイルであること、およびNagisaさんはRomanスクリプトでUSシステムを使用されていること、HFS/HFS+が混在していた時期があること等から、本現象と同じか近い現象である可能性もあると思います。
  
  Mac OS 8.1(J)のドキュメントには、日本語版以外のOS（機能拡張を使用停止している場合も含む）で起動している場合、HFS+へファイルをコピーする時はファイル名を英数字文字だけに変更してからコピーを行うようにと指示していますが、システム関連のファイルやアプリケーションが作成するファイルの場合は、勝手に名前を変更することもできませんので、Romanスクリプトでの起動時は、HFS+に対して日本語名のファイルの操作は止めておいたほうが無難でしょう。
  
  なお、上記手順による検証は、私の環境では100％再現しますが、もし検証されてみた方がいらっしゃいましたら、詳しい条件と再現したかどうかをお知らせください。

[98/04/02]

• HFS+の問題 − 表示順序のこと
  
  継続して調査中のHFS+の問題についてですが、Nagisaさんの環境で「同じ名称の初期設定ファイルが2個存在する」という問題が再現しているそうです。
  
  Nagisaさんは、HFS+だけの環境で再現しているので、私が検証した事例とは原因は異なるのかもしれませんが、結果として近い状況になっている可能性もあるかと思います。
  
  Nagisaさんは、「Greg's Browserで、問題のファイルが離れて表示される」ということを報告されています。Greg's Browserはファイル名でソートして表示を行うので、本当に同じ名称であればすぐ下に並んで表示されるはずなのです。
  
  私はGreg's Browserは使用していないのですが、手持ちの雑誌付録CD-ROMに収録されていましたので、早速確認してみました。
  
  
  
  ちょっと見づらいのですが、Finderのリスト表示（上）では「test」−「testのコピー」−「テスト」−「テスト」の順に、Greg's Browserの表示（下）は「テスト」−「test」−「testのコピー」−「テスト」の順に表示されています。
  
  ここからは先はまた推測ですが、Mac OS 8.1のTECHNOTE1121によると、HFS+ではファイル名をUnicodeで管理するため、カタログに記録されているファイル名の順序が従来のＨＦＳと異なります。
  
  このため、HFS+から起動する場合、そのままでは機能拡張がロードされる順序がHFSから起動した場合と異なる事態となってしまいます。
  
  ご存知の通り、機能拡張は読み込まれる順序によって動作が変わることがあります。
  
  そのような事態を避けるため、Mac OS 8.1のスタートアップマネージャには、従来のＨＦＳから起動した場合と同じ順序で機能拡張を読み込むようにするための機能が新たに追加されています。
  
  Finderのリスト表示はHFSでもHFS+でも同じ順序に表示されますので、こちらも従来のHFSと同じ順序で表示するような処理をしているのではないかと思います。
  
  Greg's Browserは、そのような処理をしていないため、カタログに記録されたファイル名の順序で表示を行っているのではないでしょうか？
  
  もし、そうであれば、この2つの「テスト」というファイルはどちらも同じ名称に見えますが、カタログ上は異なる名前であるという可能性（3月31日の記事参照）が高くなったといえるのではないでしょうか？
  
  残念ながら現時点では、カタログ上に記録されているファイル名を直接Unicodeで参照する手段がないため、確認できませんが．．．。
  
  なお、ここでお伝えしているHFS+の問題については、あまり反響がないのですが、「それは違う」とか「私はこう思う」等のご意見がありましたら、ぜひお聞かせ下さい。
  
  その他、HFS+に関して何か情報がありましたらお知らせください。

[98/04/04]

• カタログの話
  
  4月2日の記事などで「カタログ」と書いていたところ、WAOさんからツッコミが入りましたので（笑）、ここで簡単に説明しておきます。
  
  Norton UtilitiesやDisk First Aid等のディスクユーティリティを使用したときに「カタログBツリー」という言葉を見ることがあると思いますが、この「カタログ」のことです。
  
  Macのディスクには、ファイルの実際のデータ以外に「カタログBツリー」、「エクステントBツリー」、「マスターディレクトリブロック」等のファイルを管理するための情報が記録されています。
  （それ以外にもドライバの格納領域や起動するための情報を記録した「ブートブロック」等があります）
  
  その中の「カタログBツリー」というのは、ファイルの名前、場所、サイズや属性等の情報を記録した部分のことです。その構造が「木（Tree）構造」と呼ばれる形式であることから「Bツリー」と呼ばれています。
  
  たとえば、Finder上でファイルを削除したとき、実際にディスクに記録されているファイルのデータ自体が消されるわけではなく、これらの管理情報を変更して、そのファイルが「存在しないこと」にしてしまうだけです。
  
  データ自体はまだディスク上に残っているので、Norton UnEraseのようなユーティリティを使用することでファイルを復活させることが可能なわけです。
  
  で、前述のように、カタログにはファイルの名前が記録されているのですが、HFS+ではファイル名を内部でUnicodeで管理しているので、ファイル名がカタログに記録される順番がHFSと異なります。
  
  Mac OS 8.1のTECHNOTE 1121にも、「ディスク上でファイルが記録されている順番に依存するアプリケーションでは（HFS+とHFSで）動作が多少変わってくることがある」と記載されています。
  
  Finderのリスト表示順はHFS+でもHFSでも同じ順序ですが、Greg's Browserの表示がFinderと異なるのは、このためではないかと推測しています。
  
  以上、簡単ではありますが、こんな説明で分かります？ ＞ ALL
  
  
• 消せないファイルの消し方
  
  3月31日の記事でお伝えした「消去できない初期設定」について、宮原さんから情報を頂きました。ありがとうございます。
  
  

  乱暴なやり方ですがResEditやNorton Disk Editor等を使用しても削除出来ないファイルはMicrosoft Excelの様なOSを無視する傲慢なアプリケーションで削除出来ますよ。 バージョンにより全く手順が違いますが。 ちなみに現在のバージョン5.0はExcelのファイル検索からすべてのファイルを対象に目的のファイルを見つけ削除出来ます。 しかし、文字化けした場合特にHFS+の問題の場合は、予めマクロを作成し、ファインダーからファイル名をコピーしてファイル削除する方が正確で簡単かも知れません。 勿論アプリケーションが起動出来る環境であればの話ですが。 あとMacWORDもファイル操作が出来たと記憶しています。

  
  残念ながら（？）、私はExcelもMacWORDも使用していない（仕事でWindows版のExcelは使ってますが）ので確認できないのですが、そのようなファイルでも削除する方法はあるみたいですね。
  
  何か出来るアプリケーションがあれば試してみます。
  
  ただし、以前にも書きましたが、私の環境で発生した「名前の無いフォルダ」は、単に消せないだけでなく、実体はシステムフォルダそのものを指しているようなので、ファイルの管理情報が壊れている可能性もあると推測しています。こういう場合は強引に削除しないほうが良いかもしれません。
  
  どこかが壊れているとすると、原因を特定するのは困難だと思われますが、少なくとも私の環境では100％再現するため、「たまたまどこかの情報が壊れた」というレベルの話ではないことは確かだと思います。
  
  引き続き情報をお待ちしています。

[98/04/05]

• HFS+について
  
  佐藤さんから、HFS+に関する考察のメールを頂きました。ありがとうございます。
  
  

  私もHFS+を使っていることから、この記事に興味を持ち、自分なりに実験をしたり考えたりしててみました。 まず、POSEIDONさんのいうように、HFS+のカタログに、文字化け状態と、正常状態の二つのファイルが出来ているのだと思います。つまり、”テスト”のファイルは、テストとEeEXEg（アクセント記号は省略、というか表記しようとすると”テスト”になってしまう）となっているのでしょう。この二つを日本語フォントで表示すれば、OSが、何も変換等の処理を行ってくれなくとも”テスト”と表示されるでしょう。 ここで、HFS+は、Unicodeでファイルを管理していますが、OSとHFS+では、SHIFT-JISを使用しています。この変換を行うのは機能拡張フォルダにあるText Encoding Converterが行っています（正確にはその中のUnicodeConverter）。これは、AppearanceLib同様に、shiftを押しながらの起動でも読み込まれるようです。ただ、無理やりフォルダから出しても起動できて、HFS+がマウントできないだけでした。 で、Text Encoding Converterは、変換の際にスクリプトコードを参照して、1バイトづつ変換するか、2バイトづつにするか決めているようです。ですから、shiftを押しながら起動したときは、スクリプトコードが00（つまりUSA,またはRoman）なので、”テスト”（”EeEXEg”）をコピーするとき、Unicodeの変換で、”EeEXEg”というUnicodeになってしまったのではないでしょうか。

  
  佐藤さんも、私と同じお考えのようですね。「テスト」はShift-JISコードで「8365 8358 8367」ですが、これをJapaneseスクリプト上でHFS+へコピーすると、Unicodeの「テスト」（30c6 30b9 30c8）に変換されると思います。
  
  ところが、Romanスクリプト上では日本語文字（Shift-JIS）だと認識されませんので、文字化けしてと表示されてしまいます。この状態でHFS+へコピーすると、Unicodeの（00c9 0065 00c9 0058 00c9 0067）と変換されているのではないかと推測されます。
  
  Finderでの表示では、UnicodeからShift-JIS/ASCIIコードへ変換されているので、Unicodeの「テスト」はそのままShift-JISの「テスト」へ変換されていて、Unicodeの「」はASCIIコードの「」に変換されるのですが、これはShift-JISの「テスト」と同じ値ですから、日本語フォントでは「テスト」と表示されていると思われます。
  
  Shiftキーを押したまま起動する場合のことを少し補足しておきますと、Mac OS 8ではAppearance機能拡張が、Mac OS 8.1ではさらにText Encoding Converterが必須となり、これらの機能拡張が無いと起動できなくなる場合があります。
  （日本語システムの起動ボリュームがHFS+の場合、Text Encoding Converterが無いと起動できません。）
  
  このため、Shiftキーを押したまま機能拡張を読み込まずに起動した場合でも、これらの機能拡張は読み込まれます。
  
  

  初期設定が二つできるのも、（初期設定ファイルの名前を”テスト”と仮定すると、）コピーの際には、”EeEXEg”というファイルが作成され、アプリケーションは、”テスト”というファイルが見つからないので、新しく”テスト”を作成するのではないでしょうか。私の説が正しければ、shiftを押しながら起動した状態でアプリケーションを起動しても、初期設定は二つできないはずです。なぜなら、”テスト”のファイルを探す際の間違ったUnicode変換により、”EeEXEg”が見つかるはずですから。 ちなみに、Unicode では、コンピュータは”テスト”と”EeEXEg”を違う文字列と見ていますが、s-jisに変換することによって、同じ文字列とみなすわけですから、この二つのファイルをHFSに コピーしてみるとおもしろいかもしれません。（ディレクトリが壊れても責任はとれませんが）やってみたら是非結果を教えて下さい。

  
  初期設定ファイルについては、私の環境では再現できていないので、詳細は不明ですが、NagisaさんはHFS+のみの環境で発生しているとのことですので、HFS/HFS+間のコピー以外にも同様の問題が発生する可能性があるのかもしれません。
  
  日本語名の初期設定ファイルを作成するアプリケーションをRomanスクリプト上で起動しても、初期設定ファイルが2個作成されないことは、私も確認しています。
  
  同じような現象を経験された方がいらっしゃいましたら、ぜひ教えて下さい。
  
  それから内部的には「テスト」と「」と思われる2つの「テスト」をHFS+へコピーすると、すでに同じ名前のファイルがあるというアラートが表示されます。複数ファイルを一括コピーしても結局は一個づつのコピーなので、後のファイルがコピーされる際にアラートが出てしまいます。
  
  

  最後に、私個人の意見ですがUnicodeは良くないと思います。雑誌などでは、まるで夢の規格のように扱われることもありますが、中途半端な規格だと思います。どうせ、これからの標準にするのなら、もっと技術を熟成させ、完全なものにしてからするべきです。最近は、標準化をねらって様々な技術が中途半端なまま乱発されているように見えますが、残念なことです。

  
  そうですね。日本語だけでなく他の言語の文字も同じ仕組みで表現するという考え方自体は正しいと思うのですが、現在のUnicodeは様々な問題を抱えていますね。
  
  また、ユーザの立場で考えると、UnicodeやShift-JIS等の複数の文字コードが混在しているのが大きな問題ですね。将来Macのシステムが全面的にUnicodeを使用するようになったとしても、過去の資産や他プラットホームとの連携のために文字コードが混在することは避けられませんし。
  
  私事ですが、現在仕事でUnicode/Shift-JISの変換と文字列操作に悩まされています（笑）。
  
  引き続き、HFS+に関するご意見をお待ちしています。

[98/04/08]

• 無名フォルダの作り方
  
  継続して調査中のＨＦＳ+関連の記事で、「Romanスクリプト上でＨＦＳ+ボリュームへコピーしたシステムフォルダから起動できなくなった後、システムフォルダ中に作成される名前の無いフォルダ」（な、長い．．．）のことをお知らせしていました（3月27日記事）。
  
  
  
  この「無名フォルダ」が作成される条件が判明しましたので、ご報告したいと思います。
  
  この「無名フォルダ」は、以下の手順でも作成することが可能です（わざわざ作る方がいるとは思いませんが（笑））。
  
  (1) HFS+ボリューム上にMac OS 8.1(J)のシステムフォルダを作成。このボリュームから起動できることを確認する。
  (2) 上記システムフォルダ中の機能拡張フォルダから「Text Encoding Converter」を取り出す。
  (3) 再起動。例の文字化けしたアラート（ApperanceLibが見つからない）が表示され、起動できない。
  (4) 他のボリュームから再起動し、当該ボリュームを参照する。
  
  これにより、この「無名フォルダ」は、現在問題となっている「異なるスクリプト上でのコピー」とは直接関係がないことが分かります。
  
  もちろん関連はあると思われます。「異なるスクリプト間でのコピー」では、日本語を含むファイル、フォルダの名称が不正となり、その結果起動に必要なファイルを見つけることができなくなったものと推測されているのですが、今回の検証では、「Text Encoing Converter」が無いため、UnicodeでHFS+ディスクに記録されたファイルやフォルダの名称をShift-JISへ変換することができす、結果として「異なるスクリプト間でのコピー」の場合と同様に、起動に必要なファイルを見つけることができなかったものと推測されます。
  
  以前にもお伝えしましたように、この「無名フォルダ」は削除等ができず、しかも実体はシステムフォルダそのものである（と思われる）ことから、Disk First Aidは何の異常も報告しませんが、カタログ情報等が壊れている可能性もあると思います。
  
  「Text Encoding Converter」は、Shiftキーを押したままの起動時にも読み込まれますし、誤って使用停止にすることがないように機能拡張マネージャのウインドウにも表示されません。また起動ディスクの機能拡張フォルダから取り除いたままシステム終了や再起動を行おうとすると、アラートが表示されるので、通常は問題になることは少ないと思います。
  
  しかし、カタログ情報が壊れることがあるとすれば、現時点ではＨＦＳ+ボリュームを起動ディスクにすることは避けておいたほうが無難と言えるかもしれません。
  
  推測ばかりで申し訳ありません。ご意見などありましたらぜひお聞かせ下さい。

←TOPページに戻る

「Macintoshは米国アップルコンピュータ社の商標です」
「その他、記載の商品名などは、一般に各社の登録商標または商標です」

Copyright (C) Toshimitsu Tanaka 1998.