Opened 6 years ago

Last modified 6 years ago

#12904 new Bugs

canonical fails for relative symbolic link on NTFS

Reported by: Matthias@… Owned by: Beman Dawes
Milestone: To Be Determined Component: filesystem
Version: Boost 1.63.0 Severity: Problem
Keywords: filesystem canonical symbolic link symlink assert Cc:

Description

I've an path inside a directory which is a symbolic link at an NTFS partition. The link points to a another directory in the same base directory.

boost throws

BOOST_ASSERT_MSG(result.is_absolute(), "canonical() implementation error; please report");

in operations.cpp, line 881

Here are more details: I call boost::filesystem::canonical}} with following ({{{const wchar_t*) parameter:

L"C:\\Projekte\\50_Workspace\\out\\x64\\.\\audio\\Test.dll"

The current working directory is

L"C:\\Projekte\\50_Workspace\\out\\x64"

which is a symlink to "x64.Debug"}} in the same base directory (in {{{"C:\\Projekte\\50_Workspace\\out").

Boost detects that the "x64" is a relative symbolic link and enters the "else" in line 868. But the created new_source looks strange:

"x64.Debug/Projekte\\50_Workspace\\out\\x64\\.\\audio\\Test.dll"

In my opinion it should create either

"C:\\Project\\50_Workspace\\out\\x64.Debug\\.\\audio\\Test.dll"

or

"C:/Project/50_Workspace/out/x64.Debug/./audio/Test.dll"

for the next loop...

Change History (1)

comment:1 by Matthias@…, 6 years ago

Additional information

In operations.cpp, line 855 it declares link and creates it by calling detail::read_symlink(result, ec) result is "C:" in my case, ec is nullptr link will correctly be created as "x64.Debug" Then it calls result.remove_filename(); which leads to an empty result in my case and that's the reason why path new_source(result) also gives an empty new_source (in line 868 - which looks wrong to me...

Note: See TracTickets for help on using tickets.