関連付け解除後の不具合についてNo.02561
ecoco さん 12/01/23 00:39
 
お世話になります。
オプションから規定のファイラーにした後、解除したら
別のソフトで不具合が起きるようになりました。

具体的な不具合
1.Dropboxのタスクトレイメニューの「Dropboxフォルダを開く」を選択してもエク
スプローラが起動しない。
2.Chromeでファイルをダウンロード後表示される下部のバーより「フォルダを開
く」を選択すると、「指定されたファイルに対してこの操作を行うプログラムが関連
付けられていません。」というエラーが出る。

おそらくレジストリを変更すれば治るのでしょうが、
手動で変更することはできるだけ避けたいので、
ソフト側で処理するようにして欲しいです。

よろしくお願いします。

環境:
Windows7 Professional SP1 64bit
秀丸ファイラーClassic Ver1.01 64bit

[ ]
RE:02561 関連付け解除後の不具合についてNo.02565
秀丸担当 さん 12/01/23 11:01
 

>具体的な不具合
>1.Dropboxのタスクトレイメニューの「Dropboxフォルダを開く」を選択してもエク
>スプローラが起動しない。
>2.Chromeでファイルをダウンロード後表示される下部のバーより「フォルダを開
>く」を選択すると、「指定されたファイルに対してこの操作を行うプログラムが関連
>付けられていません。」というエラーが出る。

報告ありがとうございます。
DropboxとChromeで試してみたところ、Dropboxでは確認できませんでしたが、
Chromeでは既定のファイラーを戻した直後に数秒効かない時間があることが確認
できました。

Chromeでは、数秒待つとエクスプローラが起動しました。
そしてその後はずっとエクスプローラがすぐ開くようになりました。
Chrome側に直前の既定のファイラー情報が残っている期間があるのか、ファイ
ラーが起動されたかを待機するような処理があるような感じがしますが、Chrome
がどういうことをしているのかはわからないです。

Dropboxは既定のファイラーを解除した直後にすぐにエクスプローラが開くよう
になりました。Dropboxは1.2.49です。

秀丸ファイラーの既定のファイラーの解除の処理としては、レジストリは元に戻
しているはずと思います。

[ ]
RE:02565 関連付け解除後の不具合についてNo.02568
ecoco さん 12/01/23 13:37
 
>DropboxとChromeで試してみたところ、Dropboxでは確認できませんでしたが、
>Chromeでは既定のファイラーを戻した直後に数秒効かない時間があることが確認
>できました。
>
>Chromeでは、数秒待つとエクスプローラが起動しました。
>そしてその後はずっとエクスプローラがすぐ開くようになりました。
>Chrome側に直前の既定のファイラー情報が残っている期間があるのか、ファイ
>ラーが起動されたかを待機するような処理があるような感じがしますが、Chrome
>がどういうことをしているのかはわからないです。
>
>Dropboxは既定のファイラーを解除した直後にすぐにエクスプローラが開くよう
>になりました。Dropboxは1.2.49です。
>
>秀丸ファイラーの既定のファイラーの解除の処理としては、レジストリは元に戻
>しているはずと思います。

補足ですが、発生した環境は
CoolNovo(ChromePlus) v2.0.0.4
Dropbox v1.3.7
です。もしかしたらこちらのソフトの方の不具合という可能性もあります。

できれば検証したいので、関連付け・解除のときに
どういった処理をしているか具体的に書いていただけますでしょうか。
よろしくお願いします。

[ ]
RE:02568 関連付け解除後の不具合についてNo.02569
秀丸担当 さん 12/01/23 14:14
 

関連付けの解除では以下のことをしています。
HKEY_CLASSES_ROOT\Folder\shell の「(既定)」を削除。(「HmFilerClassic」
から「(値の設定なし)」に)
HKEY_CLASSES_ROOT\Folder\shell\HmFilerClassic を削除。
HKEY_CLASSES_ROOT\Directory\Background\shell\HmFilerClassic を削除。

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\
AutoplayHandlers\EventHandlers 配下のHmFilerClassicが含まれる各種情報を
削除。
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\
AutoplayHandlers\Handlers\HmFilerClassic を削除。

[ ]
RE:02569 関連付け解除後の不具合についてNo.02577
ecoco さん 12/01/26 17:15
 
レジストリを見ましたところ、

>HKEY_CLASSES_ROOT\Folder\shell の「(既定)」を削除。(「HmFilerClassic」
>から「(値の設定なし)」に)

の部分が削除されずに残っていました。
これを削除したところ、上記不具合はなくなりました。
他のソフトとの兼ね合いでうまく削除されなかったのかもしれません。

現時点でフォルダに対して行うその他のアクションとしては、
Orchis release 12.0105(http://www.eonet.ne.jp/~gorota/)
の「Orchisで開く」を関連付けしてました(既定の設定ではありませんでしたが)。
そのあたりの検証をよろしくお願いします。

[ ]
RE:02577 関連付け解除後の不具合についてNo.02578
秀丸担当 さん 12/01/27 10:03
 

続報どうもです。
HKEY_CLASSES_ROOT\Folder\shell の「(既定)」だけが削除されないケースとい
うのは思い当たらなくて、それができないケースでは
HKEY_CLASSES_ROOT\Folder\shell\HmFilerClassic
も削除できていないと思うのですが、こちらは削除されていたでしょうか。

あるとすれば、レジストリエディタで該当キーの右クリックして「アクセス許可
(P)...」でユーザーごとにアクセスの拒否などを指定しているときになってしま
いますが、そういう操作をすることは通常ではあまり無い気がします。


Orchisを入れてみたところ、幾つか気づく点がありました。
(Orchisの指摘になってしまいますが)

まず、Orchisのインストール時に関連付けを行うと、HKEY_CLASSES_ROOT\Folder
\shell が「(値の設定なし)」ではなく「」(=空の文字列)になってしまうよ
うです。
とはいえ、このこと自体は秀丸ファイラーの関連付け解除とは関係ないと思いま
すが、Orchisもこの場所を参照しているということなので、何らかのタイミング
で書き換える可能性はあるかもしれません。

次に、「インストール後にOrchisを起動」がONでインストールすると、管理者で
あるインストーラの権限を引き継いでOrchisが起動してしまいます。
その後、Orchisから起動するあらゆるソフトも管理者権限を引き継いでしまいま
す。
Orchisから秀丸ファイラーを起動すると、秀丸ファイラーも管理者になってしま
います。
秀丸ファイラーでの関連付けの変更は、通常は管理者への昇格が求められますが、
この状態では昇格を求められることなく書き換えできてしまいます。
この状態では様々なソフトが連鎖的に権限を引き継いでいて、いろいろ予想でき
ないことが起きる可能性があると思います。
制限ユーザーでログオンしている場合、インストーラは別のユーザーになること
もあるので、そのユーザーの権限によってはどうなるかわからないです。

再ログオンせずに休止状態やスリープをしているとこの状態はずっと続くので、
一度再ログオンしてみるといいかもしれないです。

あと、デスクトップのショートカットから起動したときや、右クリックで「管理
者として実行」したときはどうなるかや、デスクトップのショートカットのプロ
パティの「互換性」の設定など、起動の仕方によって違いが見られるようでした
ら原因を探るヒントになると思います。

[ ]
RE:02578 関連付け解除後の不具合についてNo.02579
秀丸担当 さん 12/01/27 11:43
 

>あるとすれば、レジストリエディタで該当キーの右クリックして「アクセス許可
>(P)...」でユーザーごとにアクセスの拒否などを指定しているときになってしま
>いますが、そういう操作をすることは通常ではあまり無い気がします。

1つの似た症状の再現方法がわかりました。
この、アクセス許可の操作を、Orchisのインストーラがしているようです。

通常の場合、レジストリのほとんどのキーのアクセス許可は、

  CREATOR OWNER
  SYSTEM
  Administrators
  Users

になっていると思います。

Orchisをインストールして関連付けすると、

  HKEY_CLASSES_ROOT\Folder
  HKEY_CLASSES_ROOT\Folder\shell
  HKEY_CLASSES_ROOT\Folder\shell\orchis
  HKEY_CLASSES_ROOT\Folder\shell\orchis\command

の4つのキーのアクセス許可が書き換えられ、

  RESTRICTED
  SYSTEM
  (ログオン中ユーザー)
  Administrators

と、RESTRICTEDがかかったアクセス権になってしまいました。

この状態だと、管理者ユーザーAでインストールしてから、ログオンしなおして
管理者ユーザーBでログオンすると、該当するキーはうまく読み書きできないよ
うです。


これを元に戻すには、レジストリエディタにより操作が必要なようです。
かなり危ないので十分に内容を把握しておく必要がありますが、レジストリエデ
ィタで「HKEY_CLASSES_ROOT\Folder」を[ファイル]→[エクスポート]でいったん
ファイルに書きだしておき、「HKEY_CLASSES_ROOT\Folder」を削除してから、書
きだしておいたものをインポートすると修復できました。

または「HKEY_CLASSES_ROOT\Folder」の名前の変更を繰り返す方法でも修復でき
ました。
なぜか一回目の名前変更ではRESTRICTEDがかかったキーだけがコピーされる形で
おかしな状態になって、二回目は名前の変更ができました。

[ ]