http://bugs.winehq.org/show_bug.cgi?id=59738 --- Comment #9 from BugSeeker <rikul@inbox.ru> --- One reason is portability expectations from cross-platform libraries. Code using std::filesystem typically does not distinguish between “Windows symlink” and “host filesystem symlink”; it just expects canonicalization APIs to behave consistently for the filesystem the process is actually running on. This is especially relevant for Wine because it operates inside a Linux environment and routinely interoperates with native Linux filesystems, tooling, build systems, containers, editors, and launchers, where Unix symlink resolution is part of normal path semantics. From the application perspective, Wine exposing unresolved Unix symlink components through GetFinalPathNameByHandleW() creates observable behavior differences versus both native Windows and normal Linux/POSIX canonicalization routines. If preserving “invisible Unix symlinks” is considered important for some use cases, it may be better handled through a separate Wine-specific mechanism or API rather than by changing the behavior of a standard canonicalization API that applications already rely on. Also, since this changed only after af35741d3681f21222a85900b54d95ee422fe074, existing Wine users — including us — may already rely on the previous behavior without intentionally depending on Unix symlink semantics. -- 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.