https://bugs.winehq.org/show_bug.cgi?id=50586
--- Comment #7 from Erich E. Hoover erich.e.hoover@gmail.com --- (In reply to Arnaud Dovi from comment #5)
... Wasn't aware there was 4 different one, the one I used is what I think is 2) unix symlink, created with ln -s on a directory. I also know the MKLINK.exe method but this one does not ships with wine so they are probably only creatable programmatically.
Not a problem, I was just worried that I had accidentally broken something that a Windows program was doing (but they cannot create unix symlinks). wine-staging does support mklink, but it's currently treated as a builtin command in Wine's cmd. For example (absolute directory symlink): wine cmd /C 'mklink /d C:\target C:\windows'
... To note that in some part of the staging-6.0 failing log, NtQueryInformationFile returns OK and the link is resolved if the options in create_file is 00004020 not 00204020 (FILE_OPEN_REPARSE_POINT removed)
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: 1) 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. I'm open to other opinions on the matter (option 1 is easiest to implement, BTW), so if you have thoughts I'd be interested to hear them.