Opened 6 years ago
Last modified 6 years ago
#12904 new Bugs
canonical fails for relative symbolic link on NTFS
| Reported by: | 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...


Additional information
In
operations.cpp, line 855it declareslinkand creates it by callingdetail::read_symlink(result, ec)resultis"C:"in my case,ecisnullptrlinkwill correctly be created as"x64.Debug"Then it callsresult.remove_filename();which leads to an emptyresultin my case and that's the reason whypath new_source(result)also gives an emptynew_source(inline 868- which looks wrong to me...