電脳スピーチ blog

2012年05月16日(水)20時07分

語学学習

例えば外国語を習得しようという場合、たいていの言語で「読む」「書く」「聞く」「話す」の四要素が重要になります。
これらのうち、「読む」「書く」「聞く」の三つであれば、音声CD付きの参考書や問題集などの使用で独学も可能かと思われるわけですが、「話す」に関しては、やはり「正しい発音かどうか」を判定してくれる「誰か(あるいは「何か」)」が居ないと、難しい気がします。
そこで思いつくのが、Vista や Win7 に標準で付いている「音声認識」機能を利用した学習です。
つまり、音声認識ソフトで外国語の発音練習ができないだろうか？ということなのですが、残念ながら、日本語版の Windows には日本語用の音声認識エンジンしか付いていません。
ということで、何とかして日本語版 Win7 で英語(あるいは日本語以外)用の音声認識エンジンを使えるようにしてみよう、というのが今回の内容です。

Microsoft English Recognizer v5.1

まずは「Microsoft English Recognizer v5.1」で、これは Windows で音声認識アプリケーションを作るための開発キットである「Speech SDK 5.1」に含まれており、現在(2012年05月)でも Microsoft のサイトからダウンロード可能です。
ただしこれは、もともと音声認識機能が標準搭載されていなかった頃の古い Windows 用の認識エンジンで、Vista や Win7 には非対応であり、普通にインストールしただけでは動作しません。
ですが、前回「WinXP の英語音声(Sam、Mary、Mike)を Win7 で使う」に書いた作業をすることで、一応使えるようにはなります。
とはいえ、本来 32 ビット前提の認識エンジンであるため Win7x64 等では運用に難があり、また、そもそも非対応であるものを無理やり動かすことで何かしらのトラブルもあるかもしれず、あまりお勧めはできません。

エディションが Ultimate や Enterprise の場合

次に、もしインストールされている Windows のエディションが、最上位である Ultimate や企業向けの Enterprise である場合、これは非常に簡単な方法があります。
というのも、これらの上位エディションでは、Windows の表記を他言語に変更可能な「多言語ユーザインタフェース(MUI)」という仕組みが利用でき、これらのための各種言語パックを、Windows Update 経由でインストールすれば、その言語に対応した音声認識エンジンも(存在すれば)追加されるのです。
試しに、Windows Update の「追加のオプション」に表示された、全 34 種の言語パック全てをインストールしてみたところ、以下 7 種の認識エンジンが追加されました。

• Windows 用 Microsoft 音声認識エンジン 8.0 (スペイン語 - スペイン)
• Windows 用 Microsoft 音声認識エンジン 8.0 (ドイツ語 - ドイツ)
• Windows 用 Microsoft 音声認識エンジン 8.0 (フランス語 - ヨーロッパ)
• Windows 用 Microsoft 音声認識エンジン 8.0 (英語 - 英国)
• Windows 用 Microsoft 音声認識エンジン 8.0 (英語 - 米国)
• Windows 用 Microsoft 音声認識エンジン 8.0 (簡体字中国語 - 中国)
• Windows 用 Microsoft 音声認識エンジン 8.0 (繁体字中国語 - 台湾)

ちなみに、「英語パック」に関しては、一つで「英語 - 英国」と「英語 - 米国」の2種類のエンジンが追加されます。
なお、表記言語はコントロールパネルの「地域と言語」で切り換えない限り変化はありませんので、「言語パックをインストールしたら Windows が外国語表示になってしまった！」というようなことにはなりません。
また、余談ですが、この「言語パック」のインストールは、一つ一つが結構時間のかかる処理で、今回の記事のために 34 種を一気にインストールしたところ、終了までに半日(12 時間)以上を要しました。
そして結果論として、「言語パック」の平均的な容量が 50MB 〜 60MB であるのに対し、音声認識エンジンが含まれていると思わしき言語のものは、すべて 100MB を超えていますので、この容量差を確認することで、その言語に対応した認識エンジンが存在するかどうかを判別できるようです。
それから、「言語パック」には基本的に音声合成エンジンは含まれないようなのですが、なぜか「Microsoft Lili - Chinese (China)」だけが追加されていました(簡体字と繁体字のどちらに入っていたのかはわかりませんが)。

エディションが Home Premium や Professional の場合

では、使用している Windows のエディションが、普及版である Home Premium や Professional の場合は為す術がないのか、という話ですが、これらは上位エディションのように、Windows Update から簡単に利用可能にはできませんが、言語パックを手動でインストールすることで、音声認識エンジンを追加することは可能なようです。
ただし、難易度は高めです。
また、公式に認められた使い方ではないため、何かしらの問題が起きる可能性はあり、その場合は当然ながら、Microsoft 社に責任を求めることはできませんし、当サイトでも責任は負いかねますので、必要であれば、自己の責任において実行していただくようお願いします。

【手順1】言語パックの入手

まず最初の難関が、この言語パックの入手で、これはもともと Windows Update で自動ダウンロードされることが前提であるため、Microsoft のサイトのどこかにダウンロード用のページがある、というものではありません。
とりあえず、検索サイトで「KB2483139」などを検索すると、各言語用のダウンロード URL を独自に調べて掲載しているサイトがいくつか見つかりますので、そういう情報をもとに目的の言語パックをダウンロードします。
この際、ウイルス被害などを避けるために、URL の信頼性(リンク先が Microsoft のサイトになっているかどうか等)には十分に注意を払ってください。
また、OS が「Vista か Win7 か」「x86 版か x64 版か」「サービスパックを適用しているか」で使用する言語パックが違うため、自身の環境に応じたものを探し出す必要もあります。

【手順2】言語パックの展開

次の難関がこれで、ダウンロードされた言語パックは実行ファイル形式(EXE ファイル)であり、このままでは次の【手順3】で使えないため、CAB ファイルに変換する必要があります。
そのためにまず、一度 EXE ファイル(言語パック)を実行します。
この実行自体は失敗(何のメッセージもなく終了してます)に終わるのですが、実行してから失敗するまでのあいだ、EXE ファイルと同じフォルダ内に、「lp.cab」という CAB ファイルが一時的に生成されているのです。
この一時生成される「lp.cab」を、どうにかして確保することになります。
具体的には、実行失敗によって消えてしまう前に、ほかの場所にコピーするか、あるいは名前を変更(aでもbでも何でもかまいません)します(「ファイルが使用中です」のようなメッセージが表示されても再実行で粘ると成功します)。
「消えるのが早すぎて間に合わない！」という場合には、(ハードディスクより読み書きの遅い)USB メモリや SD メモリカードなどに EXE ファイルをコピーし、そこで実行すると、少し余裕が出ると思います。
なお、「一度きりしかチャンスがない」というわけではなく、失敗しても再度実行すればまた「lp.cab」が出てきますので、何度でもチャレンジできます。

【手順3】言語パックの適用

CAB ファイルの確保まですめば、あとは簡単です。
例えば「lp.cab」を「C:\LangPack」フォルダに置いた場合、管理者権限でコマンドプロンプトを開き、以下のコマンドを実行します。

dism.exe /online /Add-Package /PackagePath:"C:\LangPack\lp.cab"

前述のとおり、結構時間がかかりますので、気長にお待ちください。

表示言語変更ツール「Vistalizator」

この表示言語変更処理を行うためのツールとして「Vistalizator」というアプリケーションがあるようです。
今回は使用しなかったため詳しくはわかりませんが、上記【手順2】【手順3】の処理を代行してくれるもののように思われます。
ツールのサイト(の日本語版)は「http://www.froggie.sk/jp/index.html」で、ここには Windows の多言語化に関するさまざまな情報や、上記【手順1】で必要になる各種言語パックのダウンロード URL 一覧などもあります。

確認

音声認識エンジンを追加した後は、「コントロール パネル → コンピューターの簡単操作 → 音声認識」の右上、「高度な音声オプション」の「言語」欄で、標準で使用するエンジンの切り替えができるようになります。
そこで切り換えて「発音を試してみよう」というわけですが、意外に「ただちょっと確認する」だけの音声認識アプリケーションというのが見つからないため、以前「Windows の音声認識を JavaScript で(基礎編)」で書いたスクリプトを再掲しておきます。

DictJS00.js ← 矢印左側の文字の上で右クリックし、「対象をファイルに保存(A)…」して保存します。

詳しくは以前の記事を見ていただきたいのですが、ダウンロードした上記「DictJS00.js」を実行しますと、「プロファイルの選択」と「音源(マイク)の選択」が表示され(たいていの場合 Enter キー二連打で OK です)、その後は延々と認識された文字の表示が繰り返されます(終わらせるときはコンソール画面右上のバツ印で閉じてください)。
ぜひとも「自分の発音が全く通じない！」という恐怖を味わってみてください。
なお、本当に「全くまともに認識されない」という場合には、一度試しに「日本語認識エンジン」に戻して、日本語で話してみてください。
「日本語ですら認識不能」レベルですと、マイクやサウンドカードの品質や設定などに問題がある可能性もあります。

【同じタグを付けた記事の一覧】
→ ソフト紹介 eラーニング Windows 音声技術 語学学習 音声認識

2012年05月11日(金)18時55分

「Microsoft Sam」「Microsoft Mary」「Microsoft Mike」を Vista や Win7 で

以前「Microsoft Speech Platform を SAPI5 として使う」のコメント欄において、「Speech SDK 5.1 でインストールされる英語音声合成(「Microsoft Sam」「Microsoft Mary」「Microsoft Mike」)を Vista や Win7 で使用する方法を知りたい」という趣旨の書き込みがありましたので、方法を記しておこうと思います。
ただし、検証不足なうえいろいろと制限や問題もあり、難易度は高めですので、「どうしても Vista や Win7 で使用する必要がある」という場合以外には、実行はお勧めしません。

ご注意

まず、この問題(SAPI5.1 が使えない)については、Microsoft のサイト「http://support.microsoft.com/kb/942400/ja」にも書かれていました。
つまり、Microsoft の方でも把握されている問題であり、しかもその原因まで明らかにされています。
にもかかわらず、「必要な場合はこのようにしてください」というような対策は示されず、そのまま「仕様」となっていることから、今回の作業(Mary や Mike を動作可能にすること)は、Vista 以降の Windows に何かしらの問題を引き起こす可能性があり、そのためにあえて動かないままにしてあるとも考えられます。
そして、実際に少し確認してみた範囲でも、結構厄介な問題が一つありましたし、他にも未確認の致命的な「何か」があるかもしれません。
ですので以下の作業は、これが原因で何かしらのトラブルに見舞われた場合でも、「自分で解決できる」という自信のある方のみ、自己の責任において実行していただくようお願いします。

x86(32ビット)用アプリケーションのみ

それともう一つ、試してみた範囲では、x86(32 ビット)用アプリケーションでの利用しか成功しておりません(「OS が 32 ビット版かどうか」ではなく「実行するアプリケーションが 32 ビット版かどうか」です)。
64 ビット版の Win7 でも、レジストリを変更することで、コントロールパネルの「音声認識」や 64 ビット版アプリケーションの話者一覧に表示させることは可能ですが、選択しても使えませんでした。
現時点(2012年05月)では、公開されているアプリケーションの多くが 32 ビット版ですので、あまり問題にはならないかとは思うのですが、もし使用したいアプリケーションが 64 ビット版である場合には、今回の作業はしても無駄ということになります。
また、64 ビット版 OS の場合、たとえアプリケーションが 32 ビット版であっても、アプリケーション側で話者を選択できるような作りになっていない場合、事実上使用できません。
これは、64 ビット版 OS では 32 ビット版アプリケーション用の「標準の話者」を変更する術がないためです(もしかしたらレジストリ書き換えなどで対応できるかもしれませんが)。

Speech SDK 5.1 のダウンロードと展開

注意点と制限について書き終えたところで、実際の作業の説明に入ります。
まず Speech SDK 5.1 のページにある「SpeechSDK51.exe」をダウンロードしてください。
この EXE ファイルは自己展開書庫となっていますので、インストールのためにいったん解凍する必要があります(実行すると表示されるダイアログで解凍先を指定し「Unzip」します)。
ここではとりあえず、以降の説明を簡単にするため、「C:\SAPI\SDK\」に展開したと仮定します。
同じページにある「SpeechSDK51LangPack.exe」は、日本語音声認識(Microsoft Japanese Recognizer v5.1)と中国語音声認識(Microsoft Simplified Chinese Recognizer v5.1)を追加するものですが、深刻な問題を引き起こす可能性(後述)がありますので、インストールしないでください。

Speech SDK 5.1 のインストール

次に、「C:\SAPI\SDK\setup.exe」を実行して Speech SDK 5.1 をインストールします(インストールが済んでも「C:\SAPI\SDK\」フォルダはまだ削除しないでください)。
x86(32 ビット)版 OS では、この時点でコントロールパネルの「音声合成」の一覧に「Microsoft Mary」「Microsoft Mike」が出現しますが、選択しても「この音声は再生されません。別の音声または別のオーディオ出力デバイスを選択してください。」というエラーが出て使えません(「Sample TTS Voice」は使用可能)。

また、「音声認識」の一覧に「Microsoft English Recognizer v5.1」が追加されますが、こちらも「必要なエンジンが作成されなかったため、要求されたタスクは実行されません。別のエンジンまたは別のオーディオデバイスを選択するか、その両方を選択してください。」となり選択できません(「SAPI Developer Sample Engine」は使用可能)。

なお、x64(64 ビット)版 OS では、見た目の変化は特にありません。

「Microsoft Speech SDK 5.1.msi」の展開

普通にインストールしただけでは、必要なファイルのいくつかがコピーされていないため、インストーラを手作業でバラして取り出さなければいけません。
そのため、以下の行を「コマンド プロンプト」を起動して入力するか、BAT ファイルにして実行します。

msiexec.exe /a "C:\SAPI\SDK\Microsoft Speech SDK 5.1.msi" targetdir="C:\SAPI\SDK\MSI" /qn

コマンドが成功すれば、「C:\SAPI\SDK\MSI」フォルダ以下に必要なファイルが展開されているはずです。

必要ファイルのコピー

上記展開処理で得られたファイルを適切な場所にコピーしますが、コピー先はシステム領域であるため、コピーには管理者権限が必要になります。
また、必要ファイルのコピー先は x64(64 ビット)版 OS と x86(32 ビット)版 OS で少し異なり、以下は x64(64 ビット)版 OS を対象としたものになりますので、x86(32 ビット)版 OS の場合は「C:\Program Files (x86)\」の部分を「C:\Program Files\」に読み替えてください。

• 「C:\SAPI\SDK\MSI\Common\SpeechEngines\Microsoft\spcommon.dll」を、「C:\Program Files (x86)\Common Files\SpeechEngines\Microsoft」フォルダにコピー。
• 「C:\SAPI\SDK\MSI\Common\SpeechEngines\Microsoft\TTS\1033」フォルダの「Sam.SDF」と「Sam.SPD」と「spttseng.dll」を、「C:\Program Files (x86)\Common Files\SpeechEngines\Microsoft\TTS\1033」フォルダにコピー。
• 「C:\SAPI\SDK\MSI\Common\SpeechEngines\Microsoft\Lexicon\1033」フォルダの「ltts1033.lxa」と「r1033tts.lxa」を、「C:\Program Files (x86)\Common Files\SpeechEngines\Microsoft\Lexicon\1033」フォルダにコピー。

DLL の登録

「http://support.microsoft.com/kb/942400/ja」に書かれている通り、SAPI5.1 でエラーとなる原因は「spcommon.dll」の不在にありますので、これを使えるようにする必要があります。
そのためには、ただ DLL ファイルをコピーするだけでなく、regsvr32 コマンドで登録しなければなりません。
それから、「Microsoft Sam」「Microsoft Mary」「Microsoft Mike」は、読み込むデータが違うだけで、その本体はいずれも「spttseng.dll」なのですが、Win7 ではこれも未登録であるため、登録しないと使えません。
ということで、「コマンド プロンプト」や BAT ファイルで以下のようにして、登録します(管理者権限で実行する必要があります)。

regsvr32.exe "C:\Program Files (x86)\Common Files\SpeechEngines\Microsoft\spcommon.dll"
regsvr32.exe "C:\Program Files (x86)\Common Files\SpeechEngines\Microsoft\TTS\1033\spttseng.dll"

なおこれも、x86(32 ビット)版 OS の場合は「C:\Program Files (x86)\」の部分を「C:\Program Files\」に読み替えてください。

「Microsoft Sam」のレジストリ追加

ここまでの作業で「Microsoft Mary」「Microsoft Mike」が使用可能になっているはずですが、「Microsoft Sam」はレジストリに登録されていないため、一覧に表示されず使えません。
これは多分、「Microsoft Mike」の情報を参考にして、名前の部分を書き換え(Mike → Sam)てもいけると思うのですが、一応 WinXP のレジストリから、「Microsoft Sam」に関する情報を抜き出してきました。
OS に応じて以下の TEXT ファイルのうちのどちらかを保存し、拡張子を「.reg」に変更して「結合」してください。

x64(64 ビット)版 OS 用「Microsoft Sam」REG ファイル

x86(32 ビット)版 OS 用「Microsoft Sam」REG ファイル

コントロールパネルのクラッシュ

今回の作業を行った場合、x86(32 ビット)版 Win7 では、「SpeechSDK51LangPack.exe」をインストールすることにより、コントロールパネルの音声認識(高度な音声オプション)で、日本語音声認識の「Microsoft Japanese Recognizer v5.1」が選択できるようになります。
しかし、それを選択して「OK」すると、コントロールパネルの音声認識機能がクラッシュし、それ以降開けなくなってしまいます。
こうなりますと、別の認識エンジンを選びなおして回避することもできなくなってしまいますので、一度「spcommon.dll」の登録を解除して、クラッシュを回避して対処する必要があります。
そのためには、regsvr32 コマンドに「-u」オプションをつけ、以下のように入力します(管理者権限で実行する必要があります)。

regsvr32.exe -u "C:\Program Files\Common Files\SpeechEngines\Microsoft\spcommon.dll"

解除後にコントロールパネルで別の認識エンジンに変更してください(その後まだ Sam や Mary を使う必要があれば「spcommon.dll」を再登録します)。
なお、x64(64 ビット)版 Win7 の場合は、そもそもコントロールパネルの音声認識に「Microsoft Japanese Recognizer v5.1」がリストアップされないため、上記の問題は発生しません。
また、英語音声認識エンジンである「Microsoft English Recognizer v5.1」ではこの問題が発生しないため、使用可能です(ただし、英語版は「SpeechSDK51.exe」の方に含まれるため、いずれにしても「SpeechSDK51LangPack.exe」は不要です)。

「spcbght.bat」と x64

例えば「テキストを読み上げ・録音するスクリプト」で公開している「spcbght.bat」というスクリプトですが、これを x64(64 ビット)版 Win7 で普通に起動すると、Sam や Mary を使えません。
これは、64 ビット OS 上でスクリプトを実行すると、64 ビット版のスクリプト・エンジン(wscript.exe や mshta.exe)によって読み込まれてしまうため、64 ビット版アプリケーション扱いとなってしまうことが原因です。
ですので、例えば「spcbght.bat」の場合、32 ビット版の「mshta.exe」である「C:\Windows\SysWOW64\mshta.exe」に直接ドラッグ&ドロップして実行すれば、Sam や Mary を使用できる状態で起動します。

【同じタグを付けた記事の一覧】
→ Windows 音声技術 音声合成 音声認識 spcbght

2012年04月20日(金)07時51分

「WinXP → Win7」で困ったこと その1(アクセス許可問題)

WinXP から Win7 へ移行するにあたって、まず WinXP 上のネット環境で、Win7 インストール時に必要となるデバイス・ドライバなどを集めました。
そのうえで Win7 を入れ、入手しておいた各種ドライバの SETUP プログラムを実行すると、「指定されたデバイス、パス、またはファイルにアクセスできません。アクセス許可がない可能性があります。」というメッセージが出て、起動できませんでした。
また、備忘録がわりに作っておいた TEXT ファイルなども、ダブルクリックするとメモ帳は起動するものの、「アクセスが拒否されました。」というダイアログが出て開けなかったりします。
しかもこれが、「WinXP で作ったファイルは全て不可」というわけでなく、使えるものもあったりするのが不思議なところです。

ファイルのアクセス権

これはどうも、NTFS に存在するセキュリティ機能である、ファイルのアクセス権が問題なようです。
とはいえ自分は、WinXP でも Win7 でも「Administrator(管理者)」としてログインして使用しています(UNIX 系の方から見れば「信じられない暴挙」で「危なっかしくて見ていられない」ことかもしれませんが Windows ユーザーにとってはわりに普通のことかと思われます)。
そして、その環境で作られたファイルには、所有者として「管理者」が設定されているはずで、同じ「管理者」であれば当然使えるはずだと思っていました(そもそも「管理者」なら全権を持っているはずなので「権限がない」などということがあるはずがない、と)。

UAC と「管理者」違い

原因として思いついたのが、WinXP にはなかった UAC(ユーザーアカウント制御)という仕組みです。
前述のとおり、Windows ユーザーは「常に Administrator」というのが一般的で、これを少しでも安全にするため、Vista 以降では管理者でログインしていても、普段は標準ユーザーとしての権限しか与えられず、必要に応じて「管理者権限の付与」を手動で認めるように変更されました。
ですので、WinXP 時代と同じく「Administrator」であるつもりが、実は単なる「User」でしかない、という状態なわけです。
もう一つ考えられることとして、ファイルのプロパティでセキュリティの項目を見ると、？マークの付いた「不明なアカウント(英数羅列)」というユーザーが、ACL(アクセス制御リスト)にリストアップされていました。
もしかしたら、これが WinXP 時の「Administrator」で、たとえ Win7 で同じ「Administrator」という名の管理者権限を与えたアカウントを作ったところで、それは WinXP の「Administrator」とは別のもの、ということなのかもしれません。
つまり、「管理者」として同格の別アカウントが作ったファイルには、同じく管理者権限を持っていても、自由にはできない、と。

うちだけ？

ただ、Windows での管理システム上の矛盾が原因であるなら、全ファイルが使用不可になっていてしかるべきで、しかも、世間的には「WinXP → Win7」という移行は、おそらくそれほど珍しいことではないと思われますので、こういう現象が起こりうるのであれば、もっと話題になっていそうなものです。
しかし、ネットで検索した限りではそういう話が書かれていることは全くなく、これはどうも、我が家の環境だけに起こった特殊な問題であると考えられます。
もしかしたら、単に自分がおぼえていないだけのことで、過去にセキュリティ強化を狙って何かしらの設定変更を「やらかして」しまっており、その影響でこんなことになってしまっているのかもしれません。

フォルダの所有権を変更してみる

まあ、理由はよくわからないのですが、いずれにしてもこれでは不便ですので、とりあえず、それらのファイルが含まれる大もとのフォルダに「Everyone」というフルコントロール権限を付加してみることにしました。
これで、そこに含まれる全ファイルに同じ権限が付与されるのではないか？と期待してのことだったのですが、そう簡単にはいきませんでした。
確かに、付与後のフォルダ内に生成したファイルには「Everyone フルコントロール」が付くのですが、既存ファイルの権限は変更されません。
ただ、変更されたものもあるような気がして、挙動がよくわかりませんでした(この辺りは変更前の状態を厳密に記録していなかったため検証できず記憶があいまいです)。

USB メモリ経由で

で、次に思いついたのが、ACL は NTFS の機能ですから、それ以外のファイル・システムに移せばいい、というものでした。
「問題のファイル」は、実行したり開いたりはできませんが、さすが「管理者」というべきかわかりませんが、コピーしたり削除したりはできるのです。
ですので、FAT32 でフォーマットした USB メモリや SD メモリーカード等に移せば、セキュリティの制限は外せるであろう、と。
実際、この方法はうまくいったのですが、この先 Win7 を使い続けるにあたって、WinXP 時代のファイルを使うたびに、いちいちこの作業をするというのはどうか…、とは思うわけです。

cacls コマンド

ということで表題へとつながるのですが、いろいろ探していると、cacls コマンドという「指定フォルダ以下に存在するファイルのアクセス権を一括で変更」できるツールがありました。
この「cacls.exe」は、少なくとも WinXP や Win7 には標準で入っていますので、改めてどこかからダウンロードしてインストールする、というような必要はありません。
これで、例えば「C:\Win7\Driver」フォルダに存在する全ファイルの所有者を、フルコントロール権限の「Everyone」にする場合、「コマンド プロンプト」や BAT ファイルで以下のようにします(Vista や Win7 では管理者権限で実行する必要があります)。

cacls.exe "C:\Win7\Driver" /t /c /g everyone:f

上記コマンドでは、既存の所有者が全削除され、「Everyone フルコントロール」のみになりますが、これを保持したままで「追加」する場合には、以下のようにします。

cacls.exe "C:\Win7\Driver" /t /e /c /g everyone:f

BAT ファイル等での確認スキップ

なお、この cacls コマンドは、普通に実行すると「よろしいですか(Y/N)?」という確認が表示され、「Y」を入力しないと先へ進みません。
通常この手のコマンドには、こういう確認を非表示で強制実行するスイッチがあったりするものですが、なぜか cacls.exe にはないようです。
ですので、BAT ファイルでの自動処理などに組み込む際に困ったりするのですが、この解決策が「caclsコマンドをバッチ・ファイルで利用する」という、そのものずばりなタイトルの記事に書かれていました。

echo y|cacls.exe "C:\Win7\Driver" /t /c /g everyone:f

上記のようにして、echo コマンドとパイプで無理やり「y」の文字を流し込めばいいそうで、「なるほど！」という感じです。

所有権は不要

ちなみに自分は当初、「WinXP でしか使えないファイルなのだから WinXP でしか変更できないだろう」と考えており、Win7 使用中に「問題のファイル」に遭遇するたび、WinXP で起動しなおして「cacls.exe」していました。
ところが、ためしにそのまま Win7 上で変更してみると、普通に変更可能でした(「cacls.exe」を管理者権限で実行する必要がありますが)。
まあ、コピーや削除はできるわけですし、そもそも本来は万能なはずの「管理者」なのですから、考えてみれば当然だったのかもしれません。

「WinXP → Win7」で困ったこと その2(BATファイルにおける半角カッコ問題)

Win7 移行後にもう一つ困ったことが、「ファイル名・フォルダ名に半角カッコが含まれると BAT ファイルが管理者権限で実行できない」という現象です。
自分は物忘れが激しいタイプなので、例えば上記 cacls コマンド用の BAT ファイルであれば、「cacls(権限付与).bat」など、半角カッコで説明書きを付けて、しばらく使っていなくても、何に使うものなのかがすぐ思い出せるようにしていました。
そしてこの「cacls(権限付与).bat」という半角カッコつきの BAT ファイル名は、普通にダブルクリックで実行する分には問題ありませんが、管理者権限で実行しようとすると失敗してしまいます。
調べてみたところ、Windows が「cmd.exe」を呼び出す方法の問題らしく、ここで半角カッコに特殊な意味が持たされていることが原因のようです。

フォルダ名も

そしてこれは、ファイル名だけの問題ではありませんでした。
当然ながら、この「内容説明のカッコ書き」はファイル名だけでなくフォルダ名にも行っており、例えばポータブルなツールを格納したそれぞれのフォルダには、「C:\Tools\FastCopy(フォルダ同期)」というように、そのツールを導入した理由を記していたのです。
で、BAT ファイル内で、そのフォルダにカレント・ディレクトリを移そうとして、「cd /d "C:\Tools\FastCopy(フォルダ同期)\"」というような行を書くと、そこで終了してしまいます。

解決策

この解決策として自分がとった方法は、「半角カッコを使わない」というものでした。
本来であれば、どうにか「半角カッコつきでも実行できるようにする」のが、「正しい」解決法かとは思いますし、その意味で何の参考にもならない内容ではありますが…。
しかしながら、自分の BAT ファイルの使用率は、確かに一般的な Windows ユーザーとしては比較的高めかとは思いますが(そもそも BAT ファイルなど使っている時点で「一般的な Windows ユーザー」のカテゴリーからはみ出ているような気もしますが)、それでも「目視で確認・手作業で修正」が可能な程度の量でしかありませんでした。
ですので、必要に応じてファイル名やフォルダ名から半角カッコを削除し、関係するBATファイルを書き換える、という「力技」で解決する方が簡単だったのです。

【同じタグを付けた記事の一覧】
→ Windows

2012年04月17日(火)00時43分

目的は VHD ファイルの省サイズ化

今回は、タイトルはずいぶん違いますが、内容的には前回「Win7 のブート VHD ファイルのダイエット」の続きとなります。
まず最初に、「表題の内容が VHD ファイルの省サイズ化にどう関係するのか？」について書いていきたいと思います。

アロケーション ユニット サイズ

Windows で、ハードディスクやメモリカードをフォーマットする際、「アロケーション ユニット サイズ」という項目を設定することができます。
Windows を含む多くの OS では、ファイル管理を効率的に行うため、ハードディスクなどを一定のサイズごとに分割し、そのブロック単位で読み書きをします。
この「アロケーション ユニット サイズ」というのは、そのブロックのサイズのことで、「クラスタサイズ」などと呼ばれることもあります。
そして NTFS においては、この「アロケーション ユニット サイズ」の値が標準で 4KB(= 4096 バイト)となっており、自分が Win7 のブート用に作った VHD ファイルも、(特に変更はしていないため)4096 バイトでフォーマットされています。

クラスタギャップ

前述のとおり、読み書きは指定したブロック単位で行われます。
そのため、例えばブロックのサイズが 4096 バイトのハードディスクに、4097 バイトのファイルを作ると、一ブロックに収まりきらないたった1バイトだけのためにもう一ブロック必要になり、「4096 × 2 = 8192」バイトを消費してしまうことになります。
この、余分に消費してしまった 4095 バイトの無駄な領域は「クラスタギャップ」等と呼ばれ、クラスタサイズが大きければ大きいほど、クラスタギャップも大きくなります。
例えば上記 4097 バイトのファイルを、クラスタサイズが 512 バイトのハードディスクに作った場合、格納のために必要なブロック数は9個、つまり「512 × 9 = 4608」バイトしか消費しませんので、クラスタギャップは「4608 ? 4097 = 511」バイトで済むことになるわけです。

最適なクラスタサイズ

では「クラスタサイズは小さいほどいいのか？」、あるいは「大きなクラスタサイズは何のために存在するのか？」という話になりますが、まず、小さすぎるとファイルを細かく分割することになりますので、分断化が起きやすくなります。
つまり、ファイル読み書きのパフォーマンスが落ちます。
また、例えばクラスタサイズ 4096 バイトのハードディスクでは、4096 バイトまでのファイルであれば「ここのブロックにあります」という情報だけで済みますが、クラスタサイズ 512 バイトの場合「ここと、ここと、ここと、ここと…、のブロックにあります」となり、つまり管理のために必要な領域が増えます。
さらに、管理できるブロックの数には上限があるため、クラスタサイズを小さくしすぎると、大容量のハードディスクに対応できなくなってしまいます。
これは、例えば簡単のために上限が10個と仮定しますと、4096 バイトで区切れば「4kB × 10」で計 40KB までのハードディスクを管理できますが、512 バイトですと 5KB までのハードディスクしかフォーマットできないということです。
ということで、「小さければ良い」というわけではなく、一般的には「細かいファイルが多い場合は小さく、大きいファイルが多い場合には大きくとるのが良い」とされています。

クラスタサイズの変更

で、ここまで来てやっと本題なのですが、OS のシステムが格納されている領域などは、比較的細かいファイルが多くなっています。
つまり、「ブート VHD ファイルのクラスタサイズを小さくすれば、クラスタギャップが解消され、VHD ファイルのサイズを減らせるのではないか？」と考えたわけです。
しかし、少し調べてみた限りでは、「すでにあるデータをそのままにクラスタサイズを変更する」というのは、一部有料ソフトぐらいでしか実現できないようでした。
さすがにそれだけのために購入するというのは避けたいと思うわけですが、そうなると考えられる手段としては、「もう一度 Win7 のインストールをやり直す」ということになり、これも面倒だな、と。
そこで、どうにか楽に、かつ安上がりにできないものかと思案してみました。

WinXP 丸ごとコピー

また少し話はそれますが、WinXP は全ファイルをコピーすることで、システムを丸ごとバックアップ(複製)することが可能です。
ただし、WinXP 起動中には、いくつかの重要なファイルがロックされていてコピーできないため、何らかの方法でそれを回避してコピーする必要があります(具体的には別の OS から WinXP に必要なフォルダ群をコピーすることになります)。
また、ルートに存在する「ntldr」というファイルが起動に必要な特殊なもので、これと「boot.ini」「bootfont.bin」「NTDETECT.COM」を併せた計4ファイルは、ハードディスク先頭領域に配置する必要があります。
そのため、「ntldr」はハードディスクのフォーマット直後にコピーし、その後「boot.ini」「bootfont.bin」「NTDETECT.COM」の3ファイルをコピー、それ以降はこの4ファイルの配置場所が変化する可能性のある操作をしないよう気を付けなければいけません。
ということで、例えば今より大容量のハードディスクを買ってきてそれと入れ替えたい場合、OS が WinXP であれば、特殊な専用のソフトを使わずとも、以下のような手順で「丸ごとコピー」が可能です。

1. WinXP に新ハードディスクを繋ぎフォーマット。
2. フォーマットした新ハードディスクに「ntldr」をコピー。
3. 続いて「boot.ini」「bootfont.bin」「NTDETECT.COM」の3ファイルをコピー。
4. 別のシステム(BartPE や WinPE など)で起動し上記4ファイル以外の全ファイルをコピー。
5. 旧ハードディスクと新ハードディスクを入れ替え。

Win7 は丸ごとコピーできるのか

ということで表題につながるのですが、つまり、Win7 も同様にファイルコピーで複製できるのであれば、お金も手間もかけずにクラスタサイズを変更できるはず、というわけです。
ただ Win7 は、WinXP 以前のシステムとの互換性や、あるいは x86 用のアプリケーションを実行するために、ジャンクションと呼ばれるリンクが張り巡らされていますので、コピーしただけでは複製できないかもしれません。
しかしまあ、たとえ単なるコピーでは起動しなかったとしても、「クラスタサイズを 512 バイトにした場合、どの程度の削減が見込めるか？」の確認にはなるはずです。
ですので、実際に再インストールするかどうかは、それを見てから決めてもいいだろうと、とりあえず「全ファイルのコピー」を試すことにしました。

FastCopy

ファイルのコピー処理には「FastCopy」というツールを使いました。
この手の、ファイルのコピーや同期を行うものとしては、今回使用した「FastCopy」と、もう一つ「Fire File Copy」というツールが有名です。
自分は過去にこの両者を比較検討した結果「FastCopy」を選択し、それ以来ずっと、データのバックアップやフォルダの同期処理にはこれを使ってきました。
ただ、「FastCopy」を選んだのは、確か何らかの理由があったはずなのですが、それがなんだったのかは忘れてしまいました(少なくとも「デザインが〜」みたいなものではなかったと思うのですが)。
なお、この「FastCopy」も、前回「Win7 のブート VHD ファイルのダイエット」で使用した「Ultra Defrag」と同様に、「コマンドラインモード」があり、「日本語対応(というより標準が日本語なのですが)」で、「ポータブル運用可」と、非常に「自分好み」な作りとなっています。
そしてその性能に関しては、前述のジャンクションやシンボリックリンクに対応し、ハードリンクを追跡して再現する機能があり、UNICODE 実装により非常に長いパス名であっても問題なくコピーできる、と、もうこれでコピーできないものならあきらめる他ないだろうと言える充実ぶりです。

【手順1】コピー元(セクタサイズ 4096 バイト)をEドライブに準備

ということで、複製作業に入ります。
稼働中の Win7 をそのままコピーしても(おそらく)うまくいかないと予想されますので、まず、デュアル・ブートで残してある WinXP で起動し、Win7 のブート VHD ファイルの複製を作りました(これを「Win7_4096.vhd」とします)。
そして Win7 で起動しなおし、Win7_4096.vhd をマウントします。
前回にも書きましたが、複製した VHD ファイルをマウントすると、初期状態が「オフライン」になりますので、右クリックで「オンライン」にして「Eドライブ」に割り当てます。

この時点での Win7_4096.vhd のサイズは 14.3GB でした。

【手順2】コピー先(セクタサイズ 512 バイト)をFドライブに準備

次に、「コマンド プロンプト」を管理者として実行し、以下コマンドを入力してDドライブの「VHD」フォルダに「セクタサイズ 512 バイト」で「NTFS 圧縮が有効」な、容量 40GB 可変の VHD ファイル「Win7_0512.vhd」を生成します(生成後は exit コマンド二回で「コマンド プロンプト」を終了できます)。

diskpart
create vdisk file="D:\VHD\Win7_0512.vhd" maximum=40960 type=expandable
select vdisk file="D:\VHD\Win7_0512.vhd"
attach vdisk
create partition primary
format fs=ntfs unit=512 quick compress

そしてその Win7_0512.vhd をマウントし、Fドライブに割り当てます。
この時点での Win7_0512.vhd のサイズは 76.6MB でした。

【手順3】FastCopy による全ファイルのコピー

両者がそろったところで、FastCopy を使い「Eドライブ → Fドライブ」の丸ごとコピーを実行します。
具体的には、管理者として実行した「コマンド プロンプト」で、以下のオプションを指定して起動しました。

fastcopy.exe /cmd=sync /force_close /open_window /bufsize=1024 /disk_mode=same /speed=full /acl /stream /reparse /linkdest "E:\" /to="F:\"

指定したスイッチを説明しますと、まず、Win7 のシステムフォルダにはジャンクションやハードリンクが張り巡らされいるため、「/reparse」や「/linkdest」を指定し、また、「/acl」や「/stream」ででアクセス権限と副次ストリームもコピーすることで、できる限り元の構造を保持するように努めています。
それから、論理的には別のハードディスクですが、実体は両方とも同一ドライブ上にありますので、念のため「/disk_mode=same」として「同一 HDD モード」を強制しておきました。
また、「/bufsize=1024」の部分で、バッファサイズとして 1GB を指定していますが、これは搭載メモリによってはエラーが出るかもしれません。

クラスタギャップは解消

コピー後に、ドライブのプロパティから両者の使用状況を比較しました。
まず、コピー元であるEドライブの使用容量は 15,403,565,056 バイト(14.3GB)でした。

これがコピー後のFドライブでは 13,549,190,144 バイト(12.6GB)となり、2GB 近く減っています。

ということで、クラスタギャップは確実に解消されています。
ただし、この時点での Win7_0512.vhd のサイズは 16.6GB と、元の 14.3GB より 2GB 以上増えています。
原因として、「管理に必要な領域が増えたため」という可能性が考えられますが、もう一つ、今回「ただコピーしただけ」ではあるものの、NTFS 圧縮をしているためか、以下の通り激しく断片化していますので、この辺りも関わっているかもしれません。

いずれにしても、前回「Win7 のブート VHD ファイルのダイエット」で確認した通り、「最適化 → 事前圧縮処理 → compact コマンド」処理を経ればまた変わってくるだろうと考え、とりあえず起動できるかの確認を行いました。

起動も可能

ということで、また WinXP で起動しなおし。現在使用中のブート VHD ファイルと、Win7_0512.vhd を入れ替えて再起動してみたところ、あっさりと起動できました。
いくつかアプリケーションを起動してみたりしましたが、特に問題もなく動作しましたので、一見したところでは、とりあえず「ファイルの丸ごとコピー」でも「複製は可能」といった感じです。
もっとも、こういったことは「長く使って初めてわかる不具合」というものもありますから、一度や二度「起動できました」という程度で断定はできないと思いますが。

VHD ファイルのサイズ削減には逆効果

で、VHD ファイルのサイズ削減のため、まず Ultra Defrag で最適化を開始したのですが、12 時間 PC をつけっぱなしにしておいても、0.1% しか進んでいませんでした。
この調子では、終了までに数日どころか数週間はかかる(それでも済まないかもしれない)、ということで、単なる「デフラグ」に変更してみたものの、進み具合に大差はありません。
ということで、仕方なく方針を転換し、とりあえず新規 VHD ファイル作成からやり直し、「事前圧縮処理 → compact コマンド」のみをやってみました。
が、Win7_0512.vhd のサイズは 16.6GB と、まったく変化はありませんでした。

クラスタサイズ 512 バイト時での処理時間増大問題

クラスタサイズを 512 バイトにすると、とにかく何をするにもすごく時間がかかるようになりました。
デフラグもそうですし、事前圧縮処理(precompact.exe)も 4096 バイトよりかなり処理時間が長くなっています。
また、起動に要する時間も伸びていて、4096 バイトでは「最初のハードディスクへのアクセスから起動音が鳴るまで」の時間が1分05秒だったのですが、512 バイトでは1分45秒と、倍とまでは言いませんが、それに近い程度は必要です。
理屈で考えれば、例えば 4096 バイトまでのファイルであれば「このブロックにあります」で済んだものが、「ここと、ここと、ここと…のブロックにあります」と、最大8倍の処理が必要になりますので、処理時間が増大するのは必然とは言えるのですが、それにしてもデフラグにかかる時間は、とても8倍どころでは収まりません。
あるいは、VHD ファイル内部では 512 バイトでも、その VHD ファイル自体は 4096 バイトのクラスタ上に存在するわけで、その矛盾が何かしらの影響を与えていたりするのかもしれません。

さすがにあきらめることに

もしかしたら、「最適化 → 事前圧縮処理 → compact コマンド」と手順を踏むことで、クラスタギャップ分の効果は出るのかもしれませんが、アプリケーションのインストールや Windows Update のたびに、数週間もかけて VHD ファイルのメンテナンスをする、というのはちょっと現実的ではありません。
ということで、さすがにクラスタサイズ変更による VHD ファイルのダイエットはあきらめることにしました。
その結果、表題の件についても、「とりあえず起動は可能」というところまでで、「継続使用で問題が出ないか」の検証については、残念ながら「やらずじまい」ということになりました。

【同じタグを付けた記事の一覧】
→ バックアップ ポータブル Windows

2012年04月12日(木)00時59分

容量固定40GB

前回「Win7 の VHD ブートと稼働中のコピー」に引き続き VHD ブート関連の話題で、今回は起動用 VHD イメージのファイルサイズを少しでも小さくしようと苦闘？した記録です。
まず、当初は容量固定で 40GB の VHD ファイルにして運用していました。
これは、「容量固定の方がパフォーマンスが良くトラブルの可能性も低い」というようなことをどこかで読んだからです。
また、40GB にしたのは「Blu-ray へのバックアップ」を念頭に置いてのことです(といっても Blu-ray ドライブ持っていないのですが)。

容量可変方式に変更

が、とりあえず必要そうなアプリケーションを詰め込んだ状態での使用容量はせいぜい 15GB 程度、そのために毎回 40GB をバックアップするのは、どうにも時間の無駄に思えたため、容量可変に変更することにしました。
変換処理は、例えば「D:\VHD\固定.vhd」を「D:\VHD\可変.vhd」に変換する場合、「コマンド プロンプト」を管理者として実行し、以下二行のコマンドを入力すればできます(終了後は exit コマンド二回で「コマンド プロンプト」を終了できます)。

diskpart
create vdisk file="D:\VHD\可変.vhd" maximum=40960 type=expandable source="D:\VHD\固定.vhd"

ただし、現在起動中の VHD ファイルから生成することはできませんので、あらかじめ別システムでコピーしておいたものをソースとして使用する必要があります。
また、コマンド中「maximum=40960」となっている最大容量指定部分は、ソースの最大容量より大きくはできましたが、小さい値を指定することはできないようです(省略するとソースと同容量になります)。
なお、「可変 → 固定」と逆に変換する場合には、「type=expandable」の部分を「type=fixed」とします(あるいは何も指定しなければ容量固定になります)。

容量可変方式の不要ブロック

上記コマンドで「固定 → 可変」に変換した直後の状態では、実際の使用容量(15GB)以上の VHD ファイル(18GB)になっていました。
これは、create コマンドが「ブロック単位」でソースのコピーを行うことが要因であるようです。
一般的な OS でのファイル管理方式では、例えばあるファイルを削除したとしても、それはファイル・テーブル(ファイル管理用データベース)上での「この位置にファイルがあります」という情報が消されるだけで、実際にファイルが記録されていたブロックのデータが消される(ゼロクリアされる)わけではありません。
つまり、ファイルを削除すると「データは残っているが使われないブロック」ができるわけですが、create コマンドではこの「使われないブロック」もコピーするため、実際の使用容量より大きくなります。

不要ブロックの削除

というわけで、さらなる省サイズ化のだめには、使用されていないブロックを削減する処理が有効となりますが、これには compact コマンドを使用します。
圧縮処理は、例えば「D:\VHD\可変.vhd」を圧縮する場合、「コマンド プロンプト」を管理者として実行し、以下三行のコマンドを入力すればできます(終了後は exit コマンド二回で「コマンド プロンプト」を終了できます)。

diskpart
select vdisk file="D:\VHD\可変.vhd"
compact vdisk

事前圧縮処理(Pre-Compactor)

ただし、いきなりこの compact コマンドを実行しても、大してサイズに変化はありません。
これは、結局のところ compact コマンドも「何も書かれていないブロックを取り除くだけ」であり、create コマンドにおけるソースのコピーと同じ方式ですから、不要ブロックにデータが残っている状態で使用しても意味がないからです。
ということで、この問題を解決するために、「Windows Virtual PC」に付属する「バーチャル ディスク事前圧縮ユーティリティ(precompact.exe)」というツールを使用します。
なぜこれが Virtual PC に付属しているのか？といいますと、もともと「VHD」という形式が、Virtual PC 用の仮想ハードディスクとして開発されたものであるためです。
現在 Virtual PC は無償提供されており、また、Win7 で VHD ブートをしているエディションであれば「Windows XP モード」もありますので、これをインストールして「precompact.exe」を入手しました。
余談ですが、自分はこの「Virtual PC」がまだ市販ソフトであったときに購入しており、しかも結構高価だったにもかかわらず思ったほど使わなかったということもあって、これが無償提供されると聞いたときには、複雑な思いを抱いた記憶があります。

「precompact.exe」の使い方

本題に戻りまして、この「precompact.exe」は、実行するとハードディスクのファイルが書かれていない領域にゼロを書き込んでいくツールです。
これが、「VHD ファイル」の各ブロックに対してゼロクリアしていくものではなく、「ハードディスク」の各ブロックを消去するものであることに注意が必要です。
つまり、これを使用するためには、その前に VHD ファイルをマウントし、OS からハードディスクとして認識されるようにしておく必要があります。
さらに、「precompact.exe」を普通にダブルクリックで実行した場合、接続されている全ハードディスクに対して実行されます。
当然ながら、物理的な実ハードディスクの各ブロックをゼロクリアしても意味もなく時間の無駄ですので、コマンドラインから「-SetDisks」スイッチを使用し、処理するドライブレターを指定して実行することになります。
例えば、対象 VHD ファイルを E ドライブにマウントしている場合は以下のようになります(最後の「e」がドライブ指定です)。

precompact.exe -SetDisks:e

このとき、ドライブは複数指定可能で、例えば「E」「G」「I」のサンドライブを順に処理する場合は以下のようにします。

precompact.exe -SetDisks:egi

また、「-Silent」スイッチを指定すると、開始時の「Would you like to prepare the virtual hard disk(s) for compaction?」という確認なしで、いきなり処理が始まりますので、BAT ファイルなどに組み込む場合に便利です。
ただし、途中経過も一切表示されない本当の Silent 処理になりますので、終了時間の予想がつきにくいのが難点ですが。

precompact.exe -Silent -SetDisks:e

Win7では事前圧縮処理は不要か？

今回、この記事を書くためにいろいろと調べている過程で、Microsoft の中の人？が書いていると思わしき、以下のページを見つけました。

http://blogs.msdn.com/b/virtual_pc_guy/archive/2009/12/14/the-different-ways-to-compact-a-disk.aspx

これを読んでいると、どうも Win7 では「ファイル単位」での圧縮が行われるらしく、この場合はあらかじめ各ブロックをゼロクリアする「事前圧縮処理」は要らないと読めます。
つまり、NTFS のファイル・テーブルを読んで必要な場所のみを残す、という処理をするため、ブロックにデータがあっても、それが使用されていなければ削除されるというわけです。
ただし、これは Virtual PC の機能として存在する？「仮想ハードディスクの圧縮」を使えば、ということのようで、試した限りでは、少なくとも diskpart の compact コマンドは、Win7 付属のものも「ブロック単位」であり、precompact.exe を実行しておく必要がありました。

NTFS 圧縮

また本筋に戻りまして、さらなる容量削減を目指し、「NTFS 圧縮」もしてみました。
ドライブのプロパティで「このドライブを圧縮してディスク容量を空ける」となっているアレです。
これもまた、過去に Windows Update で「NTFS 圧縮しているファイルが破損する」というバグがあり、その直撃を受けたという嫌な思い出があったりもするのですが、それはともかく、システム・ドライブは音声や動画といった「圧縮の効きにくいファイル」が少ないため、これは効果があるのではないか、と期待されます。
が、やってみたところ、「14.2GB → 13.7GB」と、せいぜい 500MB ほどしか縮みませんでした。
ただし、次に述べる「最適化」を行うと「12.9GB」と、なぜか 1GB 超縮みましたので、まあやった甲斐はあったかな、という程度にはなりました。

デフラグと最適化と Ultra Defrag

例えばネットで、VHD ファイル圧縮に関する情報を集めますと、大体その手順は「デフラグ → 事前圧縮処理 → compactコマンド」とされています。
「デフラグ」とは、一つのファイルが分割され、ハードディスク上で分散して格納されてしまっている場合に、それらを集めて「ひとつなぎ」にしてしまうことです。
さらにこの上位互換的なものとして「最適化」があります。
これは、ファイルごとにまとめるだけでなく、さらに全ファイルを(一般的により高速に読み書きできる)ハードディスク先頭領域にまとめてしまいます。
そして自分は、この「最適化」目的のために、「Ultra Defrag」というアプリケーションを導入しました(理由は「コンソールで使える」「標準で日本語対応」「ポータブル版がある」などです)。
もっとも、VHD の時点で「ハードディスク先頭領域にまとめる」ことの効果にはそれほど期待しておらず、「空き領域がまとめられる」ことが狙いです。
これは例えば、空き領域が分散されていて「ここと、ここと、ここと、ここと…、が空きブロックで不要です」という状態よりも、一か所にまとまっていて「ここから○ブロックが不要です」の方が、当然管理に必要な情報が少なくなり、その分 VHD ファイルのサイズも減るだろう、ということです。
ということで、さっそく VHD ファイルをマウントして「完全に最適化する」をしてみたところ、前述の通り、なぜか 500MB も圧縮容量を稼ぐことができました。

複製 VHD ファイルの同時マウント

実は今回いろいろと調べてみるまで、複製した VHD ファイルを、元の VHD ファイルと同時にマウントできる、ということを知りませんでした。
何の話かといいますと、まず今の環境は WinXP と VHD ブートの Win7 でデュアル・ブート体制になっており、Win7 の起動用 VHD ファイルは WinXP を立ち上げ、そこからコピーしてバックアップを取っています。
つまり、同じ内容の VHD ファイルが「Win7x64.vhd」と「Backup.vhd」の二つ同時に存在するわけです。
で、「Win7x64.vhd」で起動しますと、当然ながらこれが C ドライブとしてマウントされています。
この状態で「Backup.vhd」をマウントすると、以下のように「オフライン」というエラーが表示され、ドライブレターの割り当てが行われないのです。

しかし、「Windows はハードディスクごとに識別子(署名)を埋め込んで管理している」という知識があったため、「ああ、これは署名が競合するから無理なんだな」と、勝手に納得して済ませていました。
そして、今回多用している diskpart というコマンドライン・ツールは、WinXP にも存在するのですが、これはバージョンが古いため VHD ファイルを操作する機能に乏しく(というより無い？)、そういう目的にはほぼ使えません。
それで仕方なく、Win7 のインストール DVD を起動し、「SHIFT + F10」キーでコマンド・プロンプトを開いて compact コマンドを使ったりしていたのです。
ところが、調べてみるとこれは、右クリックして「オンライン」にするだけで回避(マウント)可能でした。

つまり、エラーだと思っていた「オフライン(オンラインである他のディスクと署名が競合しているために、ディスクはオフラインです)」というのは、単なる警告だったわけです。
何事も思い込みで勝手に判断せず、とりあえずは調べてみた方がいい、と思い知らされた出来事でした。

ファイル・サイズ増減の記録

最後に、この記事を書くにあたって行った、「どういう作業をすればどのくらい VHD ファイルのサイズが増え(あるいは減り)、またその際内部のブロック配置状況がどうなっているのか？」を確認するために作った記録を残しておきます。
各見出しの数値は VHD ファイルの容量、画像は、Ultra Defrag で「分析」で表示されたものです。

[00]55.3MB

8GB の可変 VHD を作り、全領域を割り当てたパーティションを一つを NTFS でフォーマットした初期状態です(「このドライブ上のファイルに対し、プロパティだけでなくコンテンツにもインデックスを付ける」をオフにしています)。
ハードディスクの管理に必要な部分(ファイル・テーブルなど)以外は、何も使用されていません。

[01]2.34GB

「ファイル数=14000個、フォルダ数=700個、サイズ=2.25GB、ディスク上のサイズ=2.29GB」のフォルダ(以下「フォルダA」)を一つコピーしました。

[02]4.61GB

「フォルダA」と同じものを、もう一つ追加でコピーしました(以下「フォルダB」)。

[03]4.61GB

先にコピーした「フォルダA」を削除しました。
ディスクの使用量は減っていますが、一度増加した VHD ファイルのサイズは減っていません。

[04]4.60GB

[03]の状態で、「事前圧縮処理」をせずに、いきなり compact コマンドを実行してみました。
しかし、当然ながら VHD ファイルのサイズはほとんど変わりません。

[05]2.35GB

[04]の状態に、「precompact.exe」で「事前圧縮処理」をかけてから compact コマンドを実行してみました。
VHD ファイルから、削除したフォルダ分の容量が削減されました。
ただし、ハードディスク前半の、削除した部分のブロックは、空きブロックとしてそのまま残されています。

[06]2.33GB

[05]の状態に、Ultra Defrag で「最適化」をしてから「事前圧縮処理」をかけ、compact コマンドを実行してみました。
ハードディスク前半部の空きブロックが後ろに回され、一つにまとめられています。
そのためか、VHD ファイルの容量もわずかながら削減されています。

[07]1.84GB

[06]の状態に、「このドライブを圧縮してディスク容量を空ける」をチェックして「NTFS 圧縮」をかけてみました。
フォルダ内には、音声や動画のような圧縮に向かないデータが少なかったせいもあり、「ディスク上のサイズ」では 1.39GB とかなり縮んでいます。
ただし、実験的にここでは「最適化」はせず、「事前圧縮処理 → compact コマンド」処理のみしてみたところ、VHD ファイルのサイズは、「ディスク上のサイズ」程には減っていません。

[08]1.48GB

[07]の状態で、「最適化 → 事前圧縮処理 → compact コマンド」処理したものです。
VHD ファイルのサイズが「ディスク上のサイズ」に近づき、かなり縮小されました。
ということで、「NTFS 圧縮 → 最適化 → 事前圧縮処理 → compact コマンド」で最大効果、ということが確認できました。

【同じタグを付けた記事の一覧】
→ バックアップ ポータブル Windows