我正在编写一个模块来运行logparser查询。我编写了一个函数来检查LogParser是否在系统根目录中,以便我可以在后续函数中将logparser作为命令运行。
我的代码:
function Add-LogParser
{
if(Test-Path "C:\Windows\System32\LogParser.exe")
{
Write-Host -ForegroundColor Cyan "Log Parser is in System Root"
}
else
{
Copy-Item "C:\Program Files (x86)\WindowsPowerShell\Modules\Dealogic.LogAnalysis\LogParser.exe" -Destination "C:\Windows\System32\" -Force
if(Test-Path "C:\Windows\System32\LogParser.exe")
{
Write-Host -ForegroundColor Cyan "Log Parser has been added to System Root"
}
else
{
Write-Host -ForegroundColor Red "Unable to add Log Parser to System Root. This is a requirement of the Dealogic Log Analysis Module. Please verify you have write to copy to the C:\Windows\System32\ folder."
break
}
}
}
我运行了该功能,并且第一次将它添加到root用户。我再次运行该函数,因为它有逻辑来检查它是否在root中并且运行正常。然后我删除了LogParser,期望它第三次看到它在那里并将它添加回root,但相反,它认为LogParser仍然存在。即使我开始新的Powershell会议,只是选择它所认为的那条路径。
即使在我的代码之外,此命令也无法正常工作:
Test-Path -LiteralPath C:\ Windows \ System32 \ LogParser.exe
这是因为它在系统根目录下吗?是否在Powershell配置文件中缓存了什么?因为将它添加到root是一次性的事情,我不知道它会影响我的脚本,但我很惊讶地看到这种行为。
答案 0 :(得分:2)
在开发人员可能意外或无意中在32位和64位Powershell环境之间切换的情况下进行开发时,这似乎是一个常见的陷阱。
我进行了以下测试:
测试:仅在system32中创建文件,并从32位和64位PowerShell中检查system32和syswow64。 结果:32位会话为两者返回FALSE。对于system32,64位会话返回TRUE,对于syswow64,返回FALSE。
测试:仅在syswow64中创建文件,并检查两个会话中的两个路径。 结果:32位会话为两者返回TRUE。对于system32,64位会话返回FALSE,对于syswow64,返回TRUE。
测试:在两个位置创建文件并检查两个会话中的两个路径。 结果:两个路径的两个会话都返回TRUE。
测试:在两个位置创建文件,仅从system32删除。 结果:32位会话为两者返回TRUE。 64位会话仅对syswow64返回true。
测试:在两个位置创建文件,仅从syswow64删除。 结果:32位会话为两者返回FALSE。 64位会话仅为system32返回TRUE。
从这次测试看来,64位版本似乎能够准确地检查system32和syswow64中的文件。 32位应用程序似乎默认使用wow64。如果文件在那里,无论system32中是什么,它都将返回true,如果文件不在那里,无论system32中是什么,它都将返回false。
感谢@Mathias R. Jessen询问该文件是否存在于syswow64目录中,因为这提醒我之前我已经看过这个。
看起来这一切都与wow64下的键的重定向和反射有关。有关详细信息,请搜索msdn Microsoft文档“受WOW64影响的注册表项”。这篇文章https://support.microsoft.com/en-us/help/305097/how-to-view-the-system-registry-by-using-64-bit-versions-of-windows
包含一些相关的信息,并包含这条有趣的信息:“为了支持32位和64位COM注册和程序状态的共存,WOW64提供了32位程序以及注册表的备用视图。” / p>