c++ - 使用 boost 解析符号链接(symbolic link)时，结果不等于原始路径名

Question

Windows 10
微软 VS 2015
C++11
boost 1.60

我创建了这个符号链接(symbolic link):

mklink/J "C:\T4 2.0\ApplicationSymlinks\T4""C:\T4 2.0\Data"

这是一个非常简化的程序版本，用于检查符号链接(symbolic link)是否链接到正确的目录:

#include <boost/filesystem.hpp>
#include <iostream>
int main()
{
    boost::filesystem::path directory = "c:\\T4 2.0\\Data";

    boost::filesystem::path symlink = "c:\\T4 2.0\\ApplicationSymlinks\\T4";
    boost::filesystem::path path_linked_to("");
    path_linked_to = boost::filesystem::read_symlink(symlink);    // Resolve symlink. path_linked_to is not absolute. L"\\T4 2.0\\Data"
    path_linked_to = boost::filesystem::absolute(path_linked_to); // Absolute path. L"c:\\T4 2.0\\Data"

    if (directory == path_linked_to)
        std::cout << "paths are equal" << std::endl;
    else
        std::cout << "paths are not equal" << std::endl;                    
    return 0;
}

输出是“路径不相等”。他们不应该是平等的吗？在调试器的自动窗口中，我确实看到了这一点:

directory size 14 capacity 15

在哪里

path_linked_to size 16 capacity 23 because it includes two trailing '\0's.

这两个尾部 '\0' 在 read_symlink 中引入。

我该如何解决这个问题？为什么 read_symlink 不返回绝对值？为什么 read_symlink 添加两个尾随 '\0'(假设这是问题所在)？为什么 operator== 不忽略 '\0'？

我是如何编译和链接的:

C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\x86_amd64\CL.exe /c /IC:\Libraries\boost_1_60_0 /ZI /nologo /W3 /WX- /sdl /Od /D _DEBUG /D _CONSOLE /D _UNICODE /D UNICODE /Gm /EHsc /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Zc:inline /Fo"x64\Debug\\" /Fd"x64\Debug\vc140.pdb" /Gd /TP /errorReport:prompt resolvesymlilnk.cpp stdafx.cpp

C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\x86_amd64\link.exe /ERRORREPORT:PROMPT /OUT:"c:\Users\Therefore\Documents\Visual Studio 2015\Projects\resolvesymlilnk\x64\Debug\resolvesymlilnk.exe" /INCREMENTAL /NOLOGO /LIBPATH:"C:\Libraries\boost_1_60_0\lib64-msvc-14.0" kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /MANIFEST /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /manifest:embed /Debug /PDB:"c:\Users\Therefore\Documents\Visual Studio 2015\Projects\resolvesymlilnk\x64\Debug\resolvesymlilnk.pdb" /SUBSYSTEM:CONSOLE /TLBID:1 /DYNAMICBASE /NXCOMPAT /IMPLIB:"c:\Users\Therefore\Documents\Visual Studio 2015\Projects\resolvesymlilnk\x64\Debug\resolvesymlilnk.lib" /MACHINE:X64 x64\Debug\resolvesymlilnk.obj

Answer 1

这是 Boost 中的一个已知错误:https://svn.boost.org/trac/boost/ticket/10900

不幸的是它还没有被修复并且被分配了一个低优先级，所以如果你想要它被修复你将不得不自己做。

问题是当 boost.filesystem 读取 REPARSE_DATA_BUFFER结构，它假设重解析是一个符号链接(symbolic link)，所以总是使用 SymbolicLinkReparseBuffer union 成员；对于联结，它应该使用 MountPointReparseBuffer。这意味着缓冲区计算被 sizeof(ULONG) 关闭，因此读取路径缺少驱动器号和冒号 (L"C:") 并且有两个宽字符相反，在末尾添加，正如您所观察到的，通常是空字符。 (宽字符在离开 boost.filesystem 内部结构时被转换为窄字符。)

修复将在 read_symlink 中检查 ReparseTag 成员是否为 IO_REPARSE_TAG_SYMLINK 或 IO_REPARSE_TAG_MOUNT_POINT(如 is_reparse_point_a_symlink )，并使用 SymbolicLinkReparseBuffer 或MountPointReparseBuffer 分别。正如上面链接的票证所说，Boost 应该真正使用 SubstituteNameOffset/SubstituteNameLength 而不是 PrintNameOffset/PrintNameLength 并去掉用于绝对符号链接(symbolic link)和联结的前导 L"\??\"。