中途半端なWindowsのシンボリック・リンク

先日のHDDクラッシュの件は，新しいHDDは届いたものの，まとまった時間が取れず，まだサルベージ作業には着手できていない。ほとんど見込みはないと思ってるので，急いでも急がなくても，大した違いはない。それより問題は今後である。

取り敢えず，定期的にバックアップを取らなければならない。バックアップ先の容量の問題もあるので，何でもかんでもコピーするというよりは，必要な物だけということになるだろう。となると，バックアップ対象のファイルが，あちこちに散らばっているのは都合が悪い。手っ取り早いのは，特定のディレクトリの下に，バックアップ対象を集めるやり方だ。例えば，\Documentsをバックアップ対象として，その下にサブディレクトリを作って，ファイルを分類して置いておくのである。ただ，今までルートにあったディレクトリは，1階層下になって，アクセスの手間が増えてしまう。そこで考えたのが「リンク」の利用である。

Windowsではあまりポピュラーではないと思うが，Linux等でよく使われる技術に，「シンボリック・リンク」というものがある。これは言わば，ファイルやディレクトリに対して，別名を付けるようなことに当たる。例えば，"C:\Documents\Photo"というディレクトリの別名として，ルート・ディレクトリに"Photo"という名前のリンクを作るのだ。こうすると，例えば

dir c:\Photo

とした時に，"C:\Documents\Photo"ディレクトリの内容をリストすることが出来る。

Windowsの場合，NTFSファイル・システムの機能を利用して実現されているので，NTFSでフォーマットされたHDDでないと利用できない。が，まぁ今どきNTFSが普通だろう。実は，元々「ジャンクション」という似たような機能があったのだが，ディレクトリのみが対象で，ファイルに対するリンクは作ることが出来なかった。それが，Vistaから，よりLinuxのものに近い，「シンボリック・リンク」がサポートされるようになったのである。今回は，ディレクトリのリンクで充分だし，ジャンクションなら以前も使ったことがあったのだが，せっかくなので，新しいシンボリック・リンクを使ってみることにした。

シンボリック・リンクの作成には，"mklink"というコマンドを使う。先ほどの例だと，コマンド・プロンプトで，

mklink /d c:\Photo c:\Documents\Photo

を実行すれば良い。但し，管理者権限が必要なので，コマンド・プロンプトを「管理者として実行」しておく必要がある。リンクが出来ると，"dir"コマンドでは

2015/01/28  23:00    <SYMLINKD>     Photo [c:\Documents\Photo]

というように，"<DIR>"の代わりに"<SYMLINKD>"と表示される。Exploreの場合は，フォルダのアイコンにショートカットの矢印が付く。

使用感は，ジャンクションと全く変わらない。ファイルのシンボリック・リンクも作れるようになったし，より便利になった...と思っていたのだが，後日思わぬ落とし穴に気付いた。

シンボリック・リンクを作ったドライブは，ネットワーク共有して，他のPCからもアクセスすることが多いのだが，ネットワーク・ドライブのシンボリック・リンクを開こうとすると，「アクセス出来ない」というエラーになってしまうのだ。先に書いたように，シンボリック・リンクは比較的新しい機能なので，古いアプリケーションでは対応していないことがある...ということは知っていたのだが，Windows付属のExplorerでも同じなのだ。これはどういうことだろう。

Linuxの場合，シンボリック・リンクというのは，文字通り，設定されたパスの文字列へリンクを張るものだ。先の例で言えば，Photoは"c:\Documents\Photo"を参照する。ネットワーク・ドライブは"c:"ではないので，それが問題なのだろうか。

そう考えて，ローカルのCドライブに，"\Documents\Photo"というディレクトリを作ってみたのだが，相変わらずエラーになる。どうも，Windowsのシンボリック・リンクは，ネットワーク共有には対応していないということのようだ。

ジャンクションの場合は，ネットワーク・ドライブでも問題なく利用できるので，結局全て，ジャンクションに作り変えることにした。せっかく機能が増えたと思ったのに，中途半端な仕様である。因みに，ジャンクションは，同じmklinkコマンドで，

mklink /j c:\Photo c:\Documents\Photo

のようにすれば作成できる。管理者権限も必要ないので，こちらの方がお手軽だ。

ワン・クリックでWindowsをロックする

小ネタ。Windows 8以降は知りません。現在稼働中のマシン(も仮想マシンも)ないため。Windows 7でのみ動作確認済み。

オフィスなどで，PCの前を離れる時，セキュリティーの観点から，画面ロックをかけることを推奨されることが多いと思う。省電力機能で，一定時間操作をしないと，ロックされるように設定している場合もあるだろうが，やはり確実なのは，その場で即ロックをかけること。これは，Ctrl+Alt+Deleteを押して(昔は所謂「三つ指ついて」などと言っていたが，最近はどうなんだろう)，「このコンピュータのロック」をクリックすれば良い。しかし，これだと2ステップ操作が必要なので，若干面倒くさい。そこで，アイコンをワンタッチすればロックできるようにしてみる。

まず，デスクトップに新規ショートカットを作る(デスクトップを右クリックしてから，[新規作成]-[ショートカット])。ダイアログが表示されるので，「項目の場所を指定してください」の欄に，

%windir%\System32\rundll32.exe user32.dll,LockWorkStation

shell32.dllの鍵のアイコン

と入力し，[次へ」をクリック。次のパネルで，「このショートカットの名前を入力して下さい」の欄には，「コンピュータのロック」など，分かりやすいものを入れる。[完了]ボタンを押したら，新しいショートカットのアイコンができてるはず。ただ，デフォルトで設定されるアイコンはそれらしくないので，変更してみる。アイコンを右クリックして，[プロパティ]を選択し，[ショートカット]タブの[アイコンの変更]をクリック。「このファイル内のアイコンを検索」の欄に

%SystemRoot%\system32\shell32.dll

と入力。アイコン一覧の枠の中をクリックすると，shell32.dllが持っているアイコンが表示される。この中の，鍵のマークがよさそうだ。[OK]ボタンを2回押して閉じる。

ここまででも，鍵のショートカットをダブル・クリックすれば，ロックできるようになっているはずだが，デスクトップがアプリケーションのウィンドウなどで隠れている場合にはちょっと不便である。そこで，再びアイコンを右クリックし，[タスクバーに表示する]を選ぶ。これで，アイコンがタスク・バーのスタートボタンの横に並んだはずだ。タスク・バーのボタンはワン・クリックで動作するので，ロックしたい時にボタンをクリックするだけで良い。

意外と便利なので，是非お試しあれ。

2.5TB HDDが故障...。

Western DigitalのGreen Label 2.5TB HDD，WD25EZRS。中途半端なサイズなので，もうあんまり売ってないみたい。

2.5TBのHDDが突然壊れた。何の前触れもなく，さほど大きくないファイルを普通にコピーしようとしたら，いきなりシャーという怪しげな音がし出して，処理が止まってしまった。一旦シャットダウンして，おそるおそる再起動したところ，一応動いているみたいなので，慌てて別のHDDにデータのバックアップを始めた。だが，数十GBコピーした段階で，また異音が。再び再起動したら，今度はカツンカツン言い始めて，全く読めなくなってしまった。これはまずい。放っておくと，ますます悪化するだけなので，電源を切って取り外した。

症状からすると，物理的な故障なのは間違いなさそうだ。クリーンルームでも使えれば別だが，とても自力でサルベージできるとは思えない。ただ，ちょっと調べてみたところ，Linuxでdd_rescueを使えば，読める部分だけHDDのダンプくらいなら取れるかもしれない。それには，2.5TBのデータの入るHDDが必要なので，それまでしばし保留。

因みに，機種はWestern DigitalのWD25EZRS。WDのHDDが壊れたのは初めて。バックアップ取っておかないのが悪いのは分かってるが，2.5TBともなるとHDDにバックアップするしかない。やっぱり，重要なデータは二重化しておくしかないか。RAIDでミラーリングするのがいいのか，別のマシンのHDDに自動同期しておくのがいいのか...。

powercfgのショートカットで電源オプションを切り替える

昨日の「電源オプション」の話の続き。

で，次善の策とは何かというと，このブログで以前も登場した(はず)"powercfg"コマンドである。様々な機能を持つコマンドだが，コマンド・プロンプトで

powercfg -SETACTIVE <SCHEME_GUID>

を実行すると，SCHEME_GUIDで指定した電源スキームに変更することが出来る。SCHEME_GUIDは，電源スキームを識別する16バイトの値だ。因みにGUIDとは"Global Unique IDentifier"のことで，世界中のあらゆるものを一意に識別するためのIDである。と言ったって，所詮有限の値なのだが，エクサにエクサをかけてもまだ足りないのだから，当分は大丈夫なのかもしれない。

それはさておき，そのSCHEME_GUIDをどうやって知るのかというと，これまたpowercfgコマンドで，

powercfg -LIST

を実行すると一覧が表示される。

>powercfg -LIST
既存の電源設定 (* アクティブ)
-----------------------------------
電源設定の GUID: 381b4222-f694-41f0-9685-ff5bb260df2e  (バランス) *
電源設定の GUID: 8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c  (高パフォーマンス)
電源設定の GUID: a1841308-3541-4fab-bc81-f71556f20b4a  (省電力)

因みに，この3つのGUIDは，ユーザーや環境によらず同じらしい。ただ，いずれにしてもハイフンも含めて36文字もの引数を指定するのは面倒なので，別名(エイリアス)を指定できる場合がある。これは

powercfg -ALIASES

を実行すると対応が一覧される。これと，スキームのGUIDを見比べるてみると，デフォルトの電源スキームは，

電源スキームの名前	別名
バランス	SCHEME_BALANCED
高パフォーマンス	SCHEME_MIN
省電力	SCHEME_MAX

のように対応しているらしい。この別名は，SETACTIVEオプションに与える，SCHEME_GUIDの代わりに指定することが出来る。

これらを使ってどうするかというと，デスクトップにpowercfg.exeのショートカットを作るのである。私の場合は，高パフォーマンスと省電力スキームとを切り替えられれば良いので，ショートカットを2つ作り，それぞれのプロパティのリンク先を，

powercfg -SETACTIVE SCHEME_MIN
powercfg -SETACTIVE SCHEME_MAX

に変更した。以前紹介したREQUESTSオプションの実行には管理者権限が必要だったが，SETACTIVEオプションには必要ないので，ショートカットをダブル・クリックするだけで，電源オプションを切り替えることが出来る。あるいは，タスク・バーにデスクトップ・ツールバーを表示するようにすれば，そこから選択することも出来る。こうすると，タスク・トレイにアイコンが表示されている時と，あまり変わらない操作感を実現できる。これだけでは現在どちらが選ばれているかは分からないが，実用上は問題ないと言っていいだろう。

そんな訳で，これでしばらく運用してみようと思う。

Windows 7のガジェットが密かに廃止になっていた...

3TB HDDのGB単価が安い。こちらはWestern DigitalのWD30EZRX

週末，遂に決心して，TV録画マシン1台をWindows 7に入れ替えた。その最大の理由は，HDDの価格だ。GPTをサポートしない32bit XPでは，2TBが限界。しかし2TB HDDの価格は，円安もあってかじわじわ上昇し，今や1GB単価が約4円。かたや，現在最安と思われる3TB HDDは，1GB単価が約3.5円。2TB HDDは，同容量で計算すると1000円ほど割高ということになる。これは意外と馬鹿にならない差である。もとより貧乏症の私としては，どうせ買うなら3TBの方を買いたい。でも32bit XPでは使えない。

とは言え，当面はまだなんとかなる。GPTをサポートしている別のPCの2TB HDDを3TBに置き換え，それを流用すればよいのだ。実は，これまでも数回同じことをしてきた。しかし，それも残りはあと2台。これまでのペースで考えると，早ければあと半年ほどしか持たない計算だ。そろそろ潮時ということかも知れない。

そんな訳で，元のXPは残したまま，別のパーティションにWindows 7をインストール。TV録画マシンは安定性が命なので，元々必要最小限のソフトしかインストールしていなかったため，ほぼ同等の環境をセットアップするのに，それほど時間はかからなかった。録画ソフトの動作も問題はない様子。まずはめでたし。これで今後は，3TB HDDに録画データを保存できる。XPに限らず，GPTに対応していない機器はまだあるので，2TBが望ましいのは変わらないのだが，まぁ仕方がない。これも時代の流れというものだろう。

ところでこのマシン，他のマシンと同様，普段は5分放置すると，自動的にスリープに移行するようになっている。TV録画だけならこれで問題ないのだが，このマシンはメディア・サーバーとしても使用している。PS3からこれに接続して，動画を視聴している時に，スリープに移行してしまっては具合が悪い。そのため，動画視聴時にはスリープしないように，電源オプションを変更しておく必要があるのだ。ところが，XPには存在した，電源オプション変更のためのタスク・トレイのツールが，Windows 7ではなくなってしまったのである。こういうところ，Microsoftはまことに気が利かない。

これは別のWindows 7マシンをセットアップした時にも経験していて，結果的に「ガジェット」を使うことで解決していた。そこで，今回も同じガジェットを登録しようと，「オンラインで追加のガジェットを取得」を実行してみると，ブラウザが立ち上がって，なんとも衝撃的なメッセージが! 「ガジェットは廃止になりました」。何? そんなニュースあったっけ。調べてみたところ，もう1年近く前には廃止になっていたらしい。セキュリティ上の理由とのこと。う～む，困った。

デスクトップに「電源オプション」のショートカットを置いておけば，切り替えにさほど手間はかからないのだが，今までのワンタッチと比べると，だいぶ面倒な気分になる。自分でプログラムを書くのはかなり面倒臭いし(そもそも，最近Windowsのネイティブ・アプリを書いてない...)。という訳で，あれこれ調べて，次善策を考えついたのだが，ここまで前置きが長くなってしまったので，続きは次回。

crontabの罠

Linuxで，タスクをスケジュール実行するのに使用するcron。cronの設定をするのに，crontabというコマンドが使える。しかし，こいつが意外と曲者

crontabで現在の設定を見るには，

crontab -l

とlオプションを使う。編集するには

crontab -e

とeオプションを使う。ところが，rオプションというのがあって，

crontab -r

とやると，設定が綺麗さっぱり消えてしまう。「r」は「e」の隣にあるから，打ち間違えると大変だ。そんな訳で，気を付けなければいけないというのは知っていた。実際，間違えてrオプションで実行してしまったことはない。ところが，罠はそれだけではなかった。

私がやってしまったのは

crontab

つまり，オプションを付け忘れて実行してしまったのだ。後から思えば，ここまでならまだ良かった。しかし，問題はその後だった。何も表示されずに止まってしまったところで，オプションを付け忘れたのに気が付いたのだが，ここで何となくctrl-Dを押してしまったのである。そして，改めて，"crontab -l"を実行してみてびっくり。設定してあったはずのタスクがなくなってしまった。

何故こんなことになったのだろうか。crontabのmanual pageには，そもそも引数なしの形式が載っていないのだ。しかし怪しいのは，

crontab [ -u user ] file

という形式。crontabにファイル名を指定して実行すると，そのファイルの内容で設定を置き換えてしまうようになっている。そしてどうも，ファイル名を指定しないと，勝手に標準入力から読み込んでしまうようだ。manual pageには，擬似ファイル名として「-」を指定した時に標準入力から読み込む，と書いてあるのだが，「-」がなくても同じ動作をするっぽい。ここでctrl-Cを押せば，実行が中止されたものを，ctrl-D，つまりEOFを押してしまったために，標準入力から空のファイルを指定したことになってしまったのである。

なんで，「-」のない場合をエラーにしてくれなかったのだろう。咄嗟にctrl-Dを打ってしまうのは手癖のようなもので，単純なキーの打ち間違いとはちょっと違う。矯正しようと思っても，なかなか簡単にはいかないだろう。こういう罠にハマる人は他にはいないのだろうか。困ったものである。せめて確認メッセージを出して欲しかった。

因みに，Debianの古いバージョン(新しいのが手元にないので)では，引数なしの場合はUsageが表示された。

IAStorDataMgrSvcの謎

なんだか奇妙な話。

メイン・マシンのWindows 7の動作が，どうも重いので，タスク・マネージャをチェックしてみた。[プロセス]タブで，「すべてのユーザーのプロセスを表示」を押してから，CPU利用率の高い順にソートしたところ，「IAStorDataMgrSvc.exe」というプロセスが，40%以上のCPUを食っている。しかも，一時的なものではなく，延々とCPUを食い続けているのだ。これじゃぁ，動作が重くなるはずである。で，一体これは何なのか。

「IA」って接頭辞からある程度想像は付いたのだが，取り敢えずプロセスのプロパティをチェックしてみると，「Intel(R) Rapid Storage Technology」というディレクトリの下にある実行ファイルだということが分かった。HDDのアクセスを高速化するらしい，Intel純正ユーティリティ(ドライバ)のひとつですな。しかし，高速化するためのものが，CPUを食い潰してしまうのでは本末転倒。以前はこんなことなかったはずなのに，どういうわけだろうか。

バージョンが古くなってしまったのかと思って，タスク・トレイのアイコンを見てみると，Rapid Storage Technology(以下，RST)のアイコンのツールチップに，"Not running"とか書かれている。おや? さらに，アイコンをクリックして出てくるメニューから，"Open Application"を選択すると，エラーになってアプリケーションが起動しない。これは一体どういうことなのか。

仕方ないので，新しいバージョンでもインストールしてみようと，最新のらしい，バージョン13.1.0.1058をダウンロードしてきた。ところが，実行してみると，.NET Framework 4.5が必要だという。ドライバのインストールごときのために，なんで.NET Frameworkの新しいバージョンなんてインストールしないといけないんだろう。釈然とはしないが，言われるままにインストールして，システムを再起動。もう一度RSTのインストーラを起動すると，「このプラットフォームはサポートされていません」だと。バカにしてるのか?

軽く殺意を覚えつつも，Readmeをチェック。デバイス・マネージャで，「Intel(R) SATA RAID controller」か「Intel(R) SATA AHCI controller」のどちらかがあるかチェックしろと? ところが，これが見当たらない。AHCIは，以前見たことがあったはずなのだが，今はどこにもない。AHCIで構成してあるはずなのに何故?

もしや，BIOSの設定がリセットされているのでは? ふと思い付いて，再起動し，BIOSの設定画面を開く。すると，あろうことか，SATAのモードが，AHCIではなくIDEになっていた...。恐らく，何かの時にBIOS設定がリセットされてしまったのだろう。デバイス・マネージャに出て来ない訳だ。早速，AHCIにセットし直して，再起動。タスク・トレイのアイコンのツールチップに"Not running"も出なくなり，アプリケーションも起動するようになった。タスク・マネージャのIAStorDataMgrSvc.exeも，ほとんどCPUを消費しなくなった。ひとまず一件落着...ではあるが，なんとも人騒がせな話である。

なお，RSTの最新バージョンは，AHCIを有効な状態にしてもインストールできなかった。原因は不明。まぁ，もはや必要もないので，良いのだけれど。結局，.NET Framework 4.5のインストールは，完全に余計な手間だったというわけで，ちょっと腹立たしくもあるが。。

Perlのunpack関数

デジタル放送を録画したMPEG2 TSファイルを，ちょっと加工する必要が生じたので，以前書いたプログラムを引っ張り出して来た。TSファイルはバイナリ形式なので，そのプログラムはC++で書いてあったのだが，いちいちコンパイルして実行という手順が煩わしい。加えて，C++で書こうとすると，データ構造やらオブジェクト指向やら，ついついちゃんとしたデザインを考えようとしてしまって，これまた面倒臭い。一時的な目的を達成するためのやっつけプログラムなら，Perlで書く方が遥かに楽なのだ。最近はすっかりその楽さ加減に慣れ切ってしまっている状況。これも年齢のせいだろうか。

という訳で，元のC++プログラムをPerlで書き直すことにしたのだが，これがとても快適。仕様の理解があやふやなところがあるので，少しずつ変更して試してみるのに，スクリプト言語は便利である。これではますますC++に戻れない。

ところが，程なく問題に遭遇。予想していたことではあるが，処理が遅いのである。1つ約3GBのファイルの読み書きに，10分もかかってしまうのだ。数が少なければそれほど問題はないが，それが50個になると500分=8時間以上になる。やっぱりC++でないとダメなのだろうか。

そこで，C++とPerlの処理速度の比較をしてみることにした。まずは最も単純に，TSファイルをコピーするだけの処理。MPEG2 TSは，188バイトのパケットの集合体なので，それを順に読み込んでは，別ファイルへ書き出す。3GBのTSファイルだと，1500万回以上の繰り返し処理となる計算だ。これを，それぞれのプログラムで実行してみたところ，いずれも約3分と大きな違いはなかった。確かに，ファイルの読み書きは，PerlでもOSのシステム・コールを呼び出しているだけだろうから，C++とそれほど差がつくはずがない。

どこで時間を食っているのかを調べるために，Perlのプログラムに少しずつ肉付けをしていくことにした。しかし，意外にもすぐに原因が判明した。unpack関数である。スカラ変数に読み込んだ188バイトのTSパケット・データを，処理しやすくするために，unpack関数で配列に変換しているのだが，これに思いのほか時間がかかるようなのだ。試したプログラムは次のようなものである。

for(;;){
	my $buf;
	my $len = read(STDIN, $buf, 188);
	last unless defined($len);
	my @buf = unpack("C*", $buf);
	syswrite(STDOUT, $buf, $len);
}

この中で，unpackの行をコメントアウトして実行すると約3分，コメントを外すと約10分となる。つまり，その他の本質的な処理には，Perlでもあまり時間はかからず，unpackでほとんどの実行時間を食っているという訳だ。しかし，unpackを使わずに，どうやってバイナリ・データを処理すればよいのだろう。

これについての根本的な解決策は未だに不明。ただ，今回のケースに限っては対策が見つかった。ふと思い付いて，最初の5バイトだけをunpackするように変えて試してみたのである。

for(;;){
	my $buf;
	my $len = read(STDIN, $buf, 188);
	last unless defined($len);
	my @buf = unpack("C5", $buf);
	syswrite(STDOUT, $buf, $len);
}

すると，実行時間は3分強にまで激減。つまり，unpackの処理時間は，unpackするデータの数に依存するということだ。今回のケースでは，そもそも全てのTSパケットのデータをチェックする必要がなかった。TSパケットの最初の数バイトからパケットIDが分かるので，必要なパケットだけ，全体をunpackするようにしたところ，1ファイル当たり3分強程度で処理できるまでに改善された。ファイルの読み書きのバッファリングを工夫すれば，もっと高速化出来る可能性はあるが，取り敢えず現状はこれで充分である。

しかし，意外なところに落とし穴があるものだ。もしかしたら，Perl遣いの人には常識なのかもしれないが。とはいえ，全パケット処理しようとすると，やはり時間がかかるので，引き続き手はないものか調査してみるつもりである。

自動スタンバイにならない時は...

以前も書いたが，自室のWindowsマシンは，全て5分間操作しないと，自動的にスタンバイに入るように設定している。といっても，最近はほとんどVM環境に移行してしまったので，メイン・マシンと，2台のTV録画用マシン，計3台のみになってしまったが。ともかく，そのお陰で，作業した後ほったらかしておいても，勝手にスタンバイになってくれるので，多少なりとも省エネになっているはず。ところが，これが時々不調になることがある。何がきっかけなのか分からないが，気が付くと自動スタンバイにならなくなってしまうことがあるのだ。寝る前に作業していて，朝起きたら電源が入りっぱなしでびっくり，という具合だ。僅かな金額とはいえ，無駄な電気代がかかってしまったことに罪悪感を感じてしまうのである。

困るのは，自動スタンバイに入れない場合でも，画面に通知メッセージのようなものは何も表示されないということ。ただ黙々と電源オン状態を続けるだけなのだ。もちろん，いくつか明らかな原因に心当たりはある。例えば，リモート・デスクトップで，他のマシンに接続している場合など。実行中のプログラムが，処理の都合上，スタンバイや画面表示オフになってては困る場合，SetThreadExecutionStateというWindows APIを使って，システムに通知することが出来るようになっている。自動スタンバイにならない一般的な原因は，これだ。PCで映画を観ている時など，何も操作はしないが，画面が消えたり，スタンバイになっては困るケースはあるので，これは必要な機能なのである。しかし，どのプログラムがどの状態を設定しているのか，調べるためのAPIはどうもないようなのだ。仕方ないので，起動しているプログラムを1つ1つ終了したりして，原因を探すしかない。といっても，中にはシステムのプロセスもあるので，これがなかなか一筋縄ではいかない。

こうしたことは，最近に始まったことではないので，以前からいろいろ調べていたのだが，情報が見つかっていなかった。ところが，今日ふと思い付いてググってみたところ，なんと解決策が見つかった! 同じようなキーワードで検索したことは過去にもあったはずなのだが，何故今まで見つからなかったのは謎である。検索のアルゴリズムなども日々更新されているはずだから，有り得ることではあるのだが。

で，その肝心の解決策とは，Windowsに付属する，"powercfg"というコマンドだ。ハイバネーション(休止状態)を無効にするために，使ったことがある人もいるだろう。「powercfg -?」として，ヘルプを見てみると，様々な機能を持っていることが分かるのだが，今ひとつ説明が不十分なため，よく理解できていなかった。まさかそんな機能があったとは。

使ったことがない人もいるだろうから，一応説明しておくと，powercfgはコマンドラインのプログラムなので，コマンド・プロンプト内で実行する。但し，管理者権限が必要となるので，普通に実行したコマンド・プロンプトではダメ。スタート・メニューの「コマンドプロンプト」を右クリックして，「管理者として実行」を選んで起動する必要がある。そこでおもむろに

powercfg -requests

を実行する。すると

DISPLAY:
なし。

SYSTEM:
[SERVICE] \Device\HarddiskVolume1\Windows\System32\svchost.exe (CryptSvc)

AWAYMODE:
なし。

というような情報が表示されるはずだ。この中で「DISPLAY:」，「SYSTEM:」，「AWAYMODE:」というのが，SetThreadExecutionState APIに指定する，ES_DISPLAY_REQUIRED，ES_SYSTEM_REQUIRED，ES_AWAYMODE_REQUIREDに対応する。DISPLAYはディスプレイのアイドル・タイマー(タイマーが0になったら消灯する)をリセットするもの，SYSTEMはシステムのアイドル・タイマーをリセットするもの，AWAYMODEはバックグラウンドで時間のかかる処理をするものだ。つまり，ここに表示されているプログラムが，自動スタンバイを阻止しているという訳だ。

早速，当該マシンで実行してみたところ，あっさり原因が判明。うっかりと言えばそれまでなのだが，DaemonToolsに，ネットワーク・ドライブ上のISOイメージをマウントしたまま忘れていたのがまずかったようだ。アンマウントして再び実行したところ，全て「なし」に変わり，めでたく5分後にスタンバイに移行した。

因みに，上の例に出ている「CryptSvc」というサービスは，何者かはよく知らないが，リモート・デスクトップで接続されている側で実行されるものらしい。このお陰で，リモートから操作中に，勝手にスタンバイにならなくて済むのだろう。

今回は「powercfg -requests」だけで解決してしまったが，もっとややこしいケースにも対応できる方法がある。一つは，

powercfg -energy

というコマンドで，電源関係のより詳細な情報を収集して，結果をHTMLファイルに出力するものだ。そしてもう一つ，どうやっても「powercfg -requests」の結果が空にならない場合に，強制的にスタンバイ等にすることができるコマンドがある。それが

powercfg -requestsoverride <呼び出し元の種類> <名前> <要求>

「呼び出し元の種類」には「PROCESS」や「SERVICE」等を，「名前」にはそのプロセスやサービスの名前を指定する。これらは，「powercfg -requests」で表示されたものを使えば良い。<要求>には，「DISPLAY」，「SYSTEM」，「AWAYMODE」を指定する。これで，各プログラムが設定している状態を無視して，スタンバイ等に入るようにできるようだ。

とても頼もしいツールを手に入れた気分。他にもまだ，自分の知らない強力なツールが隠れているのかもしれないが，こうやってたまに新しい発見があるのも面白いものだ。

Windows8.1のアカウントをローカルに戻す

最近，メイン・マシンの調子が悪いので，予備のマシンの環境を整えておこうかと，久し振り(1年振りくらいか?)に電源を入れてみた。てっきりWindows 7がインストールしてあったと思ったのだが，なんと起動したのはWindows 8。インストールしたことすら忘れていた。

あまりWindows 8を常用したいとは思わないのだが，Windows 7を入れ直すのも面倒。完全に移行する訳ではないし，取り敢えず耐えられなくなるまで使ってみることにした。で，折角なので，まず8.1にアップグレード。

8から8.1には無償でアップグレード出来ると聞いていたのだが，どうやってやるのだろう。調べてみると，Windowsストアで出来るそうだ。実はWindowsストアを利用するのは初めて。(既にうろ覚えだが)ストアにアクセスしたら，「8.1にアップグレード出来ます」というようなメッセージが出たので，それにしたがって進めると，ダウンロードが始まった。時間がかかりそうなのでしばらく放っておいたら，アップグレードまであっさり終了。再起動を要求されるので，その通りにする。起動すると，初期セットアップが始った。たかがアップグレードなのに，何をそんなに設定することがあるのだろう，と不審に思いながらも，言われたままに情報を入力する。これが罠だった。セットアップが終了したら，ログインがMicrosoftアカウントになってしまっていたのだ。確かに，8.1のリリースの時に，何かの記事で読んだ気がする。しかし，全く忘れてしまっていた。8.1なんて縁がない，と思っていたせいもあるだろうが。

試しにそのまま少し使ってみたのだが，どうも気持ちが悪い。ファイル共有などは，アップグレード前のアカウント名で出来るらしい。コマンドプロンプトで，"net user"とやって表示されるのは，Microsoftアカウントではなく，元のアカウント名だ。どうもこれを「ローカル・アカウント」と呼ぶらしい。しかし，Windowsへのログインは，Microsoftアカウントとそのパスワードだ。コントロール・パネルのユーザー・アカウント・アプレットで見ても，対応するローカル・アカウント名は表示されない。今回はアップグレードだったが，8.1をクリーン・インストールした時は，どうやってローカル・アカウント名を知るのだろうか。

さらに気持ち悪いのは，Microsoftアカウントとパスワードで，家のマシンにログインできてしまうこと。もしMicrosoftアカウントの情報が漏洩したら，家のマシンにもログインできてしまう訳? まぁ，実際は外部から直接アクセスできるようにはなっていないので，それほど心配はないが，やはり一抹の不安はある。8.1って，Microsoftアカウントでないと使えないのだろうか。

ということで，またまた調べてみたところ，ユーザー・アカウント・アプレットで，Microsoftアカウントとの「関連付けを解除する」ことが出来るそうだ。「PC設定でアカウント変更」をクリックすると，「関連付けを解除する」という項目が現れる。いや，確かにそういうのがあるのは目に入っていたが，「関連付け」じゃ分かりにくいだろう。とにかくクリックしてみる。すると，パスワードの入力画面が現れる。ローカル・アカウントのパスワードをここで設定する訳だ。かくして，私のWindows 8.1は，めでたくローカル・アカウントの設定に戻った。

それにしても，毎度のことながら，たかが小数点以下のマイナー・アップデートごときで，押し付けがましい使い勝手の変更である。元に戻せるくらいなら，デフォルトでは元のままにしておいて欲しいものだ。Microsoftアカウントに関連付けていないことのデメリットがあるのか分からないが，しばらくこのまま様子を見てみたい。