https://bugs.winehq.org/show_bug.cgi?id=50804
--- Comment #38 from Erich E. Hoover erich.e.hoover@gmail.com --- (In reply to Zebediah Figura from comment #37)
... I forgot that kernel32 doesn't ever use FSCTL_GET_REPARSE_POINT, though even then it'd probably be a good idea to make sure that windows kernel32 is otherwise agnostic about the actual tag. (Incidentally I don't know if there are exhaustive tests for *all* kernel32 path/file functions with symlinks, but there really should be.)
Yeah, it has CreateSymbolicLink for FSCTL_SET_REPARSE_POINT - but I am not aware of any routines that actually _read_ them without going into ntdll. FindNextFileW does so currently, but it can be implemented without that because it only looks at the tag (on my list to simplify).
I would have proposed IO_REPARSE_TAG_SYMLINK until we encountered this bug. Once I add support for it, IO_REPARSE_TAG_LX_SYMLINK could do the trick. As the code currently stands it's working with unix paths, but we might need to get clever when shell32 gets converted to PE.
PE conversion is the main reason, yes. Ideally we should use FSCTL_SET_REPARSE_POINT in place of symlink(2).
Yup, that's what I'll do - the thing that will get tricky is that when shell32 gets converted to PE that we'll need a way to properly convey the paths. IO_REPARSE_TAG_LX_SYMLINK works with straight-up unix paths (what we use right now), I assume that when this is converted to PE that we'll want to work with NT paths (though maybe we work with the "\??\unix" prefix when that happens?).