On 8/31/21 6:16 AM, Martin Storsjö wrote:
On Sat, 28 Aug 2021, Alexandre Julliard wrote:
I would first question the assumption that these have to be actual, resolvable symlinks. What if they weren't?
I guess one drawback is interoperability with cases where you run commands in a mixed wine/native environment, i.e. mostly operate directly on the filesystem with native tools, but run some subcommands that are use wine for executing foreign binaries. (I e.g. have setups for using MSVC in this fashion.)
I don't have a concrete case where such tools would need to create symlinks though, just raising it as a potential use case.
(With the current patchset, with the extra bits encoded in the symlink path, they do look quite weird, but if they resolve and work as regular symlinks, that's always a plus.)
How useful are Windows symlinks, though? As far as I understand normal users aren't allowed to create them by default, and only a few applications even bother using them for any reason. Granted, I might not have a particularly accurate picture of the situation.
Many applications break if there are symlinks in parts of the path they don't expect—in theory use of symlinks should be transparent if you're not asking for them, but they try to be symlink-aware and screw it up in one way or another (I can pull out bug reports if necessary). We have to kind of weirdly half-hide Unix symlinks to Windows applications as a result.
(Disclaimer: I'm not attached to either solution.)