http://bugs.winehq.org/show_bug.cgi?id=59738 --- Comment #2 from BugSeeker <rikul@inbox.ru> --- I understand that Unix symlinks themselves are not guaranteed to exist on Windows, and applications cannot generally rely on Unix-specific filesystem behavior. However, the issue here is about GetFinalPathNameByHandleW() behavior on Wine versus Windows. On native Windows, when opening a file via a symbolic link, GetFinalPathNameByHandleW() returns the fully resolved final path — i.e., the target of the symlink — not the original path containing the link. I have verified this on Windows, and the results confirm that the path returned points to the target, not the symlink itself. This is what applications like std::filesystem::weakly_canonical rely on: the resolved, canonical path of the file handle. So this is not about Unix symlink semantics per se, but about matching Windows API behavior, which Wine aims to emulate. Windows test result: ------------------- mklink C:\workarea\link.txt C:\workarea\real.txt symlink_test.exe c:\workarea\link.txt Input path: c:\workarea\link.txt GetFinalPathNameByHandleW result: \\?\C:\workarea\real.txt std::filesystem::weakly_canonical result: C:\workarea\real.txt -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.