https://bugs.winehq.org/show_bug.cgi?id=50586
--- Comment #8 from Hans Leidekker hans@meelstraat.net --- (In reply to Erich E. Hoover from comment #7)
Okay, it looks like what would have happened before (FILE_OPEN_REPARSE_POINT did not work correctly) was that pre-6.0 wine-staging would have followed the link to the target and reported information on the target. So, I have a few sane ways that I can handle this that I'm considering:
- treat unix symlinks as an NT symlink (0xA000000C) targeting the Z:\ or
??\unix path 2) treat unix symlinks as a custom NT reparse point ('UNIX'/0x58494E55?) targeting the unmodified unix path 3) treat unix symlinks as not being NT reparse points at all and always follow them to the target
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.