https://bugs.winehq.org/show_bug.cgi?id=50586
--- Comment #10 from Erich E. Hoover erich.e.hoover@gmail.com --- (In reply to Hans Leidekker from comment #8)
(In reply to Erich E. Hoover from comment #7)
... I'm leaning towards option 2 to try and keep unix symlinks distinct from the NT symlinks and to potentially allow programs built to work with wine to create unix symlinks if they wish. The downside of this option is that it's possible that poorly-coded Windows programs would see the unusual reparse tag and do something dumb.
Doesn't this argue for 3? If an app is Wine-aware there should be other ways to create unix symlinks. I think transparent unix symlinks is a useful feature that users may already depend on.
I've actually put together a little tech demo on completely transparent symlinks to reduce the size of the prefix by using symlinks for the fake/real dlls. It would not be too difficult for me to modify this to look for "no recognized tag" instead of "special Wine tag". I can probably do that this weekend if you think that's worth it.
(In reply to Zebediah Figura from comment #9)
Note that a symlink can span file systems. It seems possible that a Windows application would be confused about a file residing on a different file system than its containing directory. That's already the case, and maybe not worth worrying about, but if we're going to make a grand final design of how symlinks work it might be worth taking into account...
Are you talking about applications that look for files based on inode? We could conceivably report the inode of the symlink in the case of a transparent symlink like this (and this is a feature that wouldn't be too hard to add in the future).