So-net無料ブログ作成
  • ブログをはじめる
  • ログイン
ソフトウェア ブログトップ
前の10件 | -

FSDirWalkerでFile Management APIのファイルの復元を利用する [ソフトウェア]

FSDirWalkerのバージョン2.2から、回復コンソールなどの保守環境で実行され、更にWindowsのFile Management APIが使用可能な環境では、ディスク上から削除されたファイルの復元機能を利用できる様にしました。

通常はWindows 10やWindows 8の保守環境(トラブルシューティング→詳細オプション→コマンドライン)からFSDirWalkerを実行した場合に、[ツール]メニューから機能を選択できます。

Windows 7,Windows Vistaの場合は、専用のFMAPIをダウンロードしてインストールする必要があり、尚且つ保守環境でもFMAPI.DLLが利用できる状態(DLLロードパスを通すかロードできる位置にDLLをコピーする)にする必要があります。

詳細は、Windows PEWindows REWindows ADKなどのページを参照してください。





で、ここからはシステムに詳しい方向けなのですが…

通常のWindows 10やWindows 7上でファイルの復元機能を利用する方法です。

レジストリに「フェイク」キーを作成するので最初に断っておくと、ここで作成するキーを削除せず残したままWindowsをシャットダウンしたり再起動すると、Windowsを起動できなくなる様です(復旧するには、回復コンソールでレジストリエディタを使い、レジストリハイブを手動でロードして、作成したキーを削除しなければならなくなります)。

このキーの下に、例えば'AllowRefsFormatOverNonmirrorVolume'(以前ネット上で流れていたReFSでフォーマット可能にするための非公式エントリ。現在は無効になっている様です)などのエントリが存在すると再起動が可能な場合もある様ですが、いずれにせよ公式にサポートされている機能ではありません。

その為、あくまでも技術的な参考情報として、もしお試しになる場合もあくまで自己責任でお願いします。
(この記事で後述する、万一の際に回復コンソールを使用して復旧操作に自信が無い時は止めた方がよいかもしれません)

条件:
Windows 10、Windows 8.1の場合はFMAPIは既にインストールされています。
Windows 7の場合は、専用のFMAPIをダウンロードしてインストールする必要があります。
Update for Windows 7 (KB943790) File Management API 32ビット版
Update for Windows 7 (KB943790) File Management API 64ビット版

手順:
  1. レジストリエディタを起動する。

  2. 以下のキーを選択する。
  3. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control

  4. 右クリックしてメニューから[新規]->[キー]を選択する。

  5. 新しく"MiniNT"キーを作成する。
  6. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\MiniNT
    というキーパスになります。
    ※もし、既に存在していたなら作成は不要です。

  7. この状態でFSDirWalkerを「管理者モード」で実行すると、リボンの[ファイル](Windows7は[アプリケーション])タブの[ツール]項目に[削除されたファイルの復元]が表示されます。

  8. [削除されたファイルの復元]を選択すると、ウィザードが表示されるので、後はその指示に従って操作します。

  9. 機能を使用し終わったら、必ず上記で追加したレジストリキー("MiniNT")を削除します。
    ※元から存在していた場合は削除は不要です。


繰り返しになりますが、ここで作成した"MiniNT"キーを消し忘れたままシャットダウンするとWindowsが起動しなくなりますので十分注意してください。

もともとこのキーは、Windowsの各種保守モード・環境で使用される様です。そのため通常モードのブートシークエンスの中で誰かがこのキーを発見すると、そこから何らかの設定を読み込もうとしますが、MiniNTキーだけ存在しエントリが何も無い状態だと必要な情報を得られず、参照したモジュールなりタスクなりがブートの途中で「止まってしまう」(現状としてはブートを繰り返す)のだと推測しています。



FSDirWalkerをお使いの方向け(非公式)

次のレジストリキー
HKEY_CURRENT_USER\Software\YamashitaSoftwareWorks\FSDirWalker

の下に、次のエントリを作成してください。
ForceEnableMiniNT (REG_DWORD) = 0x3

このエントリを作成し、FSDirWalkerを管理者モードですればレジストリのMiniNT関連の操作を自動で行います。ただし、ファイルの復元ウィザードを表示中に、なんらかの理由でFSDirWalkerを終了(タスクマネジャから強制終了したりアプリケーションエラーが起きたりなど)させたり、PCをシャットダウン(停電とかブルースクリーンなど)してしまうと、同じ様にMiniNTキーが残ってしまいますので注意してください。前者の場合はレジストリエディタで削除できますが、シャットダウンしてしまうと問題が起きる可能性があります。



もしもMiniNTを消し忘れて、Windowsが起動しない場合

私も何度もやってしまいました…。自分自身に対する戒めとしても記しておきます。
  1. 回復コンソールを起動します。
  2. コマンドプロンプトを開きます。
  3. レジストリエディタを起動します。
  4. HKEY_LOCAL_MACHINEを選択し[ファイル]メニューの[ハイブの読み込み]を選択します。
  5. 立ち上がらなくなったWindowsのシステムドライブを探し、以下のファイルを選択します。
    <ドライブ>:\Windows\System32\config\SYSTEM
    ※回復環境のWindowsフォルダと取り違えない様に注意。
  6. 追加したハイブに適切なキー名を指定します。
    例) Win10
  7. 上記で指定したキー名の下からMiniNTを探します。
    例) HKEY_LOCAL_MACHINE\Win10\ControlSet001\Control\MiniNT
  8. MiniNTキーを削除します。
  9. 6.で追加したハイブを選択し、[ファイル]メニューの[ハイブのアンロード]を実行します。
  10. 回復コンソールを終了し、Windowsを起動します。

nice!(0)  コメント(0) 

FSDirWalker 2.2.322.0を公開しました [ソフトウェア]

FSDirWalker 2.2.322.0を公開しました。ダウンロードはこちらからできます。

ファイルの属性としてFILE_ATTRIBUTE_PINNED,FILE_ATTRIBUTE_UNPINNEDなどを追加し、属性を表示する箇所の更新をしました。

また、今回から、ファイルの検索機能で検索ファイル名に正規表現を使用できる様にするモジュールを添付しました。

nice!(0)  コメント(0) 

FSDirWalkerをSets対応にする方法 [ソフトウェア]

Windows 10のRS5向けに、(今のところ)「Sets」と呼ばれるデスクトップのウィンドウをタブでまとめる機能の評価が始まっています。

現在はまだ開発途中なので動作が不安定だったりしてまだまだなのですが、正式に搭載されることになるとアプリケーションそのものの操作性は基本的には変わりは無いものの、タブ切り替えに関係してデスクトップ全般の操作性に影響が出る(特にPCに慣れていないユーザーは面食らうのではと思いますが…)ため、動向に注目しています。

Win32のアプリケーションもSetsのタブに入れることができるのですが、ウィンドウのキャプションバーが通常の(一般的な)状態になっていないと有効にならない様です。現時点のビルドではリボンを使っているアプリケーションもSetsが有効になりません。Windows Ribbon Frameworkという標準のリボンフレームワークを使っていても同じで、Windows添付のペイントやワードパッドもSetsタブの仲間に入れません。同じフレームワークを使っているFSDirWalkerも当然Setsを利用できません。

しかし、WindowsエクスプローラのウィンドウはSetsを利用できる様になっています。
エクスプローラはWindows Ribbon Frameworkを使ってきた筈なので、エクスプローラ側での特別なSets対応や使用するフレームワークを変更していない限り、将来のWindows 10ビルドでは他のWindows Ribbon Framework使用アプリケーションもSetsを利用できる様になると予想してはいるのですが。

それでも、今の段階でFSDirWalkerをSetsのタブに入れて試してみたい。もしそういった要望がある様でしたらレジストリを操作する必要があるものの、リボンを無効化してクラシックメニューにすることで利用可能にできます。

それにはレジストリエディタを使って以下のレジストリキー下に値を追加します。
(恐らくこの記事の内容に興味を持たれる方であればレジストリエディタの扱いには慣れていると思うので、おなじみの警告をくどくどとはしませんが、注意はしてください(^^;)

HKEY_CURRENT_USER\Software\YamashitaSoftwareWorks\FSDirWalker DisableRibbon(REG_DWORD)=0x1

この値を設定してからFSDirWalkerを実行してください。一般的なWin32アプリケーションの様なUIになってSetsが有効になっているはずです。

リボンUIに戻す場合は、この値に0x0を設定するか、DisableRibbonエントリを削除してください。

nice!(0)  コメント(0) 

FSDirWalker 2.2.320.0を公開しました [ソフトウェア]

先日、FSDirWalker 2.2.320.0を公開しました。ダウンロードはこちらからできます。
今回の主な機能追加・変更点は次のとおりです。
  • ナビゲーションペインに[シェルフォルダ]を追加

    Windowsシェルで定義済みのフォルダをナビゲーションペインから選択できる様にしました。

  • リボンの操作タブに[オブジェクト]ドロップダウン、[オブジェクトIDの生成][オブジェクトIDの削除]コマンドを追加

    NTFSフォーマット下のファイルで使用できるオブジェクトIDについて、生成または削除するコマンドを追加しました。コンテキストメニューからも選択できます。

  • [ファイル](アプリケーション)タブのメニューに[ツール]メニューを追加

    この項目は、実行時のモードによって表示される項目が変わります。

    • 管理者モードで実行時

      [仮想ハードディスクのアタッチ]
      仮想ハードディスクファイル(*.VHDファイル)をアタッチします。

      [システム起動時に処理される一覧を編集]
      PC起動時にセッションマネージャによって処理される以下のレジストリエントリの内容を編集します。
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager
      PendingFileRenameOperations

    • ユーザーモードで実行時

      [システム起動時に処理される一覧を参照]
      PC起動時にセッションマネージャによって処理されるレジストリエントリの内容(編集と同じエントリ)を表示します。


  • コピー開始ダイアログに[オブジェクトIDを持っている場合コピー先に移譲する]オプションを追加

    コピーされるファイルがオブジェクトIDを持っている場合、そのIDをコピー先のファイルに「移譲」します。オブジェクトIDはシステム全体で一意であり、同じIDが存在できないため、コピー元のIDは削除されます。


  • Windows PE/RE(回復コンソール)で実行時に、削除されたファイルを復元する機能を追加

    WindowsのFile Managemant APIが利用可能な環境でのみ有効になります。この機能は一度削除されたファイルの復元を試みます。通常このコマンドが使用できる環境はリボンが表示されないため、クラシックメニューの[ツール]項目から選択します。ウィザードが表示されるので、その指示に従って操作してください。
    この機能については別途記事を書く予定です。


  • オプションの[ファイル固有のアイコンを表示]と[ダブルクリックでファイルを開く]項目のデフォルトを'有効'(初回起動時から有効になる様に)に変更

    ファイルリスト上でファイルをダブルクリックした時に、シェルに登録されたアプリケーションを使ってファイルを開くオプションと、実行ファイルの様に固有のアイコンを持っている場合、ファイルリストのアイコンに表示するオプションをデフォルトでONにしました。従来はデフォルトでOFFになっており、オプションダイアログから変更する必要がありました。

他にも複数の不具合を修正しています。

nice!(0)  コメント(5) 

ServiceWalker Preview [ソフトウェア]

ServiceWalker Preview版を公開しました。

公開ページはこちらから。

svcwalker.png

ServiceWalkerはWindowsサービスを管理・制御するツールです。

コア部分は、実は10年以上前に書いたDriverWalkerの流用です。DriverWalkerのWindowsサービス処理関係を抜き出し、Windows Vista~Windows 10で追加された機能に対応する部分を一部追加して、現代風の(とはいえ5~6年前のWindows7 Ribbonスタイルですが)皮を被せて整えました。

また、UIの基本言語をFSDirWalkerと同様に英語としています。
旧DriverWalkerのコードも一部ハードコードされていた日本語をリソースに分離しました。

もちろん私の英語は「中高6年勉強して読み書き会話が出来ない」の典型なので、多分おかしな英文になっていると思うのですが、「英語が出来る様になってから英語でUIを実装しよう」なんて考えていると永遠にその機会は訪れないので、多少恥をかいてでもと思ってやってます。

これには理由があって、過去、本当に希にでしたが、私の公開しているソフトに関して海外の方から「英語版はないのか」と問い合わせがあったことです。ProcessWalkerなどは「なんなら英語版に移植するけど」みたいな提案も頂いたこともあるのですが、あまりにソースコードとリソースの分離と整理が出来ていなかったので断念したこともあります。

また、やはり海外の方から「英語版が無いのになぜソフト名が英語なの?」と訊かれて答えに困ってコトも…

なので、まあ、現状ではこの先海外のユーザが現れるとは考えにくいですが、万一に備えて英語対応(なんなら他の言語でも可能な様に)しております。オープンソースにできれば良いのかもしれませんけどね。

FSDirWalker 1.2を公開しました [ソフトウェア]

FSDirWalker 1.2.220.0を公開しました。

簡易検索の結果から簡単なファイル操作を行える様にした他、ファイルのリネームコピーなどのコマンドを追加ししました。

ダウンロードはこちらから:
http://www001.upp.so-net.ne.jp/yamashita/products/fstools/fsdirwalker/fsdirwalker.htm"

詳細な履歴はこちらから。

fsdw.png

コメント(0) 

FSJournalWalker Beta2を公開しました [ソフトウェア]

FSJournalWalker Beta2を公開しました。

ダウンロードはこちらから:
http://www001.upp.so-net.ne.jp/yamashita/products/fstools/fsjnlwalker/fsjnlwalker.htm

部分的な変更や修正、BugFixに加えて、日本語リソースを追加しました。

コメント(0) 

FSJournalWalker Betaを公開しました [ソフトウェア]

10月3日にFSJournalWalker を公開しました。

現在はBeta版とさせていただいております。

ダウンロードはこちらから:
http://www001.upp.so-net.ne.jp/yamashita/products/fstools/fsjnlwalker/fsjnlwalker.htm

NTFSなどファイルシステムがサポートする、変更ジャーナルの内容を表示するツールです。
変更ジャーナルとはファイルの作成や削除、書き込みなど各種変更イベントを記録する(変更の内容ではなく「変更された」という事実だけを記録する)Windowsの機能です。

変更ジャーナルはユーザーが有効/無効を設定でき、有効になっている場合このFSJournalWalkerでジャーナルレコードを参照できます。

余談ですが、税務関係の査察の際に、この変更ジャーナルの内容を調べられたとか。

自分自身で使用していたものを、なんとかネットで公開できるレベルまで整備したものですので、粗削りではありますが、一般的な使用状況のデスクトップ/ノート/タブレットPC等の環境では使用できると思います。

コメント(0) 

FSDirWalker 1.1を公開しました [ソフトウェア]

8月29日にFSDirWalker 1.1.200.0を公開しました。

ダウンロードはこちらから:
http://www001.upp.so-net.ne.jp/yamashita/products/fstools/fsdirwalker/fsdirwalker.htm"

新機能としてACLエディタ及び代替ストリームエディタを追加しました。また、簡易的ながらファイルリストに表示されるファイルのドラッグ&ドロップにも対応しました。

詳細な履歴はこちらから。

コメント(0) 

FSDirWalkerを公開しました (4) [ソフトウェア]

このタイトルの連載としては最後です。

内部の細かい話が中心でしたので、今回はUI周りについて書きたいと思います。

その前に、(3)の補足というか、おまけを。
ネイティブAPIにRtlGetLongestNtPathLengthという関数があります。名前からしてパスの最大値が得られるのではと期待したのですが、実際は269という値が返る(Windows 7の場合)だけです。

_RtlGetLongestNtPathLength@0:
7753D8BF  mov         eax,10Dh 
7753D8C4  ret
(Windows 7の場合)

269(0x10D)という値は何なのでしょう?他のバージョンのWindowsがどんな値を返すか確認していませんし、歴史的経緯も判りませんが(少なくともWindows2000には存在しました)当初はこの値だったのでしょうか。それともファイルパスのことではないのでしょうか?
―◇―

FSDirWalkerはUIデザインを含め仕様・設計思想自体が一回り、いや二~三回りほど古くさいと感じられるかもしれません。
書き始めたのが6年前なので仕方ないといえば仕方ないのですが(6年間と言っても連続してずっとという訳ではありません。時間があり、思い出した時に少しずつという感じでしたが、1年ぐらい間が開いたこともあります)。
その間にWindows Vista,Windows 7の”ゴージャスな”デスクトップからWindows 8/8.1のMetro(あえてメトロと呼びます)とフラットデザイン、そしてWindows 10のUWPとどんどん変化してますが、FSDirWalkerの基本はWindows XP、いやWindows 2000/NT4スタイルのままです。

まあ、これは私自身が時代に追いつけない「ロートル」だからですが、他にも多少の理由があります。

扱う対象がファイルシステムでしたのでWin32ベースになることは必然なものの、UIまで生のWin32で書くのはもはや厳しい。しかしMFCは避けたい。
極初期の頃はProcessWalker系列が使っている「フレームワーク」(Win32ベースで独自に起こしたUIライブラリ)を使用していたのですが、しばらく使ってみると今回のアプリケーションの目的に対しても、保守の面からも「重量級」に感じられす様になったのです。
そこで元々興味があったWTLが良いのではないかと思いつき、試しに使ってみたところ比較的使いやすく、使えそうなクラスも多かったのでUI部分を中心に採用することにしました。
その後、ファイル処理コアやネイティブAPIを扱うライブラリなどを残して「独自フレームワーク」を使っていた部分を捨て、UIを一から書き直して全面的にATL/WTLに移行した経緯があります。

その上で、ATL/WTL以外はWPFや.NETも含め可能な限り外部のランタイムライブラリに依存しない様に意識しました。そのため、.NETがインストールされていない環境や、Windows保守モードのコマンドプロンプト(Windows PE/REといった最小限のGUI環境)からも実行可能となっています。

とは言え、WTLもパーフェクトではなく、好みのデザインするためにいろいろ回避しなければならなかったのですが、その辺はいずれ機会があれば記したいと思います。

とりあえず連載形式は今回で終わりにしますが、今後も引き続きトピックを見つけて記事を載せる予定です。

コメント(0) 
前の10件 | - ソフトウェア ブログトップ

この広告は前回の更新から一定期間経過したブログに表示されています。更新すると自動で解除されます。