前言
因为一次偶然的机会，需要访问系统目录“C:/Windows/System32“文件夹下的内容，使用的测试机器上预装了win7 64系统。在程序运行中竟然发生了该文件路径不存在的问题！！通过查看网上相关的资料，了解到64位系统下，System32(同时也包括Program Files)这两个文件夹被动态地重定向了。为了可以直观的反映这个问题，这里将编写一个小的测试程序进行验证。
实例验证
首先随机选择一个文件，并将其拷贝到系统目录的System32文件夹下。本文选择QQ启动程序进行验证（主要是QQ自带企鹅图标易于辨认，哈哈），如图1所示
图1 手动将QQ拷贝到系统System32文件夹下
编写实际测试程序，直接上代码（调用了windows系统API PathFileExists来判断文件是否存在）
/************************************************************************/
/* file : 验证在64位机器上system32以及Program Files的exe不能用API直接找到
* author : Huagang Li
* date : 2014-8-23 01:22:55
* tips : 64位系统下system32 文件夹重定向机制
*
*/
/************************************************************************/
#include <Windows.h>
#include <string>
#include <tchar.h>
#include <Shlwapi.h> #pragma comment(lib,"Shlwapi.lib") // PathFileExists链接时需要 int WINAPI WinMain( __in HINSTANCE hInstance, __in_opt HINSTANCE hPrevInstance, __in_opt LPSTR lpCmdLine, __in int nShowCmd )
{
std::wstring strFile = L"C:\\Windows\\System32\\QQProtect.exe"; if (::PathFileExists(strFile.c_str()))
{
::MessageBox(NULL, _T("文件存在"), _T("Good"), MB_OK);
}
else
{
::MessageBox(NULL, _T("文件不存在"), _T("Opps"), MB_OK);
} return EXIT_SUCCESS;
}
运行的结果如图2所示：
图2 文件不存在？？
从上面的结果可以看出，在调用windows API检测QQ文件是否存在时，系统给出了一个令人匪夷所思的结论：文件不存在！！但这个文件确实被拷贝进了该目录下啊。要解释这个奇怪的现象，就得从windows 64位系统中的文件系统重定向说起。当微软开发了64位系统时，为了做到向前兼容，需要重新实现32为系统中需要的相关文件（system32文件夹下的dll以及exe）。然而，这些新的实现版本是基于64位系统开发的，因此如果继续存放于System32文件夹下，显得名不副实。可是为了做到向前兼容，又需要将这些依赖文件存放于这个目录下，为了解决上述冲突，微软采用了一种文件系统重定向机制：在64位系统下，System32文件夹下的文件实际重定向到SysNative这个文件夹（注意，这个文件夹不能直接找到）。这样，就可以将64位系统下64位的库和应用程序存放于System32文件夹下（因为已经重定向到SysNative了），而32位的库和应用程序则被存放在另一个叫做SysWOW64的文件夹中。具体的对应关系为：
\Windows\SysWOW64 文件夹下存放32位的库和应用程序 （WOW64 == Windows on Windows 64 bit ）
\Windows\System32 文件夹下存放64位的库和应用程序
为了验证文件系统重定向，将前文中的测试路径改为：
std::wstring strFile = L"C:\\Windows\\SysNative\\QQProtect.exe";
测试结果如图3所示：
图3 改为Sysnative结果
上述结果显示了，64位系统下如果需要访问System32目录下的文件，一个可行的方法是将访问路径改为SysNative。但是由于sysnative文件夹不能通过windows资源管理器访问到（如图4所示），因此对于一般人来讲，这样的改名其实很困惑。
图4 资源管理器访问不到Sysnative文件夹
既然微软开发了文件系统重定向机制机制，那就可以通过一定的方式操作这种机制。通过查看msdn可以发现，http://msdn.microsoft.com/en-us/library/aa365743.aspx 提供的方式可以禁用文件系统重定向问题。因此，本文尝试调用这个API接口进行验证：
/************************************************************************/
/* file : 验证在64位机器上system32以及Program Files的exe不能用API直接找到
* author : Huagang Li
* date : 2014-8-23 01:22:55
* tips : 64位系统下system32 文件夹重定向机制
*
*/
/************************************************************************/
#include <Windows.h>
#include <string>
#include <tchar.h>
#include <Shlwapi.h> #pragma comment(lib,"Shlwapi.lib") // PathFileExists链接时需要 int WINAPI WinMain( __in HINSTANCE hInstance, __in_opt HINSTANCE hPrevInstance, __in_opt LPSTR lpCmdLine, __in int nShowCmd )
{
std::wstring strFile = L"C:\\Windows\\System32\\QQProtect.exe";
// 64位系统下 system32 文件系统重定向 PVOID OldValue = NULL;
Wow64DisableWow64FsRedirection(&OldValue);
if (::PathFileExists(strFile.c_str()))
{
::MessageBox(NULL, _T("文件存在"), _T("Good"), MB_OK);
}
else
{
::MessageBox(NULL, _T("文件不存在"), _T("Opps"), MB_OK);
}
Wow64RevertWow64FsRedirection(OldValue); return EXIT_SUCCESS;
}
运行后得到的结果和上文中Sysnative一样，如图5所示：
图5 禁用文件系统重定向机制后的结果
注意，由于禁用文件系统重定向后可能引起其他一些问题（例如原本依赖于System32下的dll文件加载失败），因此在禁用并完成需要的操作后，要回复原来的禁用状态（如程序中Wow64RevertWow64FsRedirection(OldValue);）。这样，在调用PathFileExists后，恢复了文件系统重定向机制，不会影响后续操作。
另外，64位系统下Program Files与Program Files(x86)的关系就与上面的System32和S也是WOW64一致，也存在文件系统重定向。
结论
1. 64位系统下存在文件系统重定向机制（File System Redirector）
2. System32文件夹动态被定向到SysNative文件夹
3. 可以通过windows API Wow64DisableWow64FsRedirection禁用这种定向机制
参考链接
[1] http://msdn.microsoft.com/en-us/library/aa384187.aspx