2

ruby を使用して Windows 7 の system32 ディレクトリ内のすべてのファイルを印刷すると、一部のファイルが欠落します。この単純なディレクトリ反復を使用します。

Dir.foreach("C:\\Windows\\System32") do |fname|
  puts fname
end

存在しますが、印刷されていないpython27.dllを特に探しています。ファイルが存在しています？dir 反復と同じ問題があるようです。既存のファイルに対して false を返します。

File.exists? "C:\\Windows\\System32\\python27.dll" #returns false

フォルダーの別の既存のファイルを確認すると、次のように機能します。

File.exists? "C:\\Windows\\System32\\quartz.dll" #returns true

しかし、既存のファイルを複製したり、system32 で新しいファイルを作成したりしても機能しません。

File.exists? "C:\\Windows\\System32\\quartz2.dll" #returns false

また、python27.dll を別のディレクトリにコピーして存在を確認すると、次のように動作します。

File.exists? "C:\\Otherfolder\\python27.dll" #returns true

この問題は、大文字と小文字またはパス区切り文字とは関係ありません。私はそれをチェックしました。また、機能するファイルと機能しないファイルのユーザー権限に違いは見られません...

なぜこれが起こるのか、私には本当にわかりません...誰でもこれを再現できますか???

ありがとう

[編集]

少し時間がかかりましたが、答えが見つかりました。

これは 32/64 ビットの問題でした。32ビットアプリケーションとしてのrubyの場合、「C:\Windows\System32」は実際には「C:\Windows\SysWOW64」です。64 ビットの WinExplorer が示したように、python27.dll は System32 にありました (64 ビットのプロセスだけが見ることができます - まあ、紛らわしいです)。Pythonの32ビットバージョンをインストールすると、問題が解決しました（rubypythonの一部であるため、rubyスクリプトを変更できなかったため）。

4

3 に答える 3

3

Windows 7 (実際には Vista) では、以前のバージョンの Windows では紙の上にしか存在しなかった多くのセキュリティ ポリシーが、オペレーティング システムによって実際に適用されるようになりました。たとえば、Microsoft のドキュメントによると、書き込みC:\Windows\System32は何十年も前からほとんど違法でしたが、実際に試してみると、まだ機能していました。もう違います。Vista の時点でC:\Windows\System32は、立ち入り禁止です。

ただし、既存の (壊れた) アプリケーションを壊さないようにするために、Microsoft はファイルシステムの仮想化を導入しました。アプリケーションが に書き込もうとするとC:\Windows\System32、サイレントに にリダイレクトされC:\Users\%Username%\AppData\Local\VirtualStore\Windows\System32ます。したがって、この特定のアプリケーションは で作成または変更したすべてのファイルを認識しますC:\Windows\System32が、他のアプリケーションは変更されていない/空のディレクトリのみを認識します。

これはC:\Windows\System32、他のシステム ディレクトリだけでなく、他のシステム ディレクトリにも当てはまります。HKEY_LOCAL_MACHINEまた、たとえば、レジ​​ストリのシステム部分にも適用されます。

この仮想化はアプリケーションごとです。つまり、アプリケーション A が保護されたディレクトリでファイルを作成または変更しようとすると、Windows はその呼び出しをインターセプトし、VirtualStore にリダイレクトします。また、このリダイレクトをどこかに記録します。ここで、同じアプリケーション A が再びそこを検索しようとすると、Windows は記録されたリダイレクトを使用するため、アプリケーションはファイルが置かれた場所にあると認識しますが、実際にはまったく別の場所にあるのです。

ただし、別のアプリケーション B がそのディレクトリを参照すると、リダイレクトはトリガーされず、B は元のシステム ディレクトリを参照するだけです。これが要点です。以前は、異なるアプリケーションがシステム ディレクトリ内の互いのファイルを上書きすることによって、あらゆる種類の奇妙なバグを作成していました。つまり、あるアプリケーションがそのファイルを にダンプpython27.dllしC:\Windows\System32、別のアプリケーションが独自のわずかに異なる互換性のない のバージョンをダンプして、最初のバージョンを上書きします。python27.dll

したがって、あるアプリケーションを使用してそこに DLL をコピーし (おそらくexplorer.exe)、別のアプリケーションを使用して、つまりruby.exeそれを調べます。しかし、実際にはそれを にコピーせず、 explorer.exeVirtualStoreにリダイレクトされました。を使用すると、リダイレクトがトリガーされ、ファイルを配置したと思われる場所にファイルが表示されますが、を使用すると、リダイレクトはトリガーされず、実際のディレクトリが表示されます。system32explorer.exeruby.exe

きっと_ _

File.exists? "C:/Users/#{ENV['Username']}/AppData/Local/VirtualStore/Windows/System32/python27.dll"

戻りますtrue。

于 2012-08-25T14:15:17.557 に答える
2

ファイルがで利用可能であると確信していますC:\\Windows\\System32\\か？

-folderからこの問題はわかりませんが、System32-folderであなたのような問題が発生しましたProgram Files。

一部のシステムフォルダーにデータを保存しようとして、管理者でない場合、Win7はその場所ではなく、ユーザー固有の仮想ストアにデータを保存します。システムフォルダを見ると、仮想ストアのファイルもそこに表示されます。しかし、道は別のものです。

どこにいても仮想ストアをチェックできますc:\users\<username>\Appdata\local\Virtual Store\（少なくともプログラムフォルダはそこにあります）。

于 2012-08-25T14:10:29.847 に答える