https://bugs.winehq.org/show_bug.cgi?id=50586
--- Comment #41 from Erich E. Hoover erich.e.hoover@gmail.com --- (In reply to Zebediah Figura from comment #40)
(In reply to Erich E. Hoover from comment #39)
... I'll see if I can find some time this weekend to dig out my old windows box, as I can probably "put this to bed" by recreating this behavior on windows with the same symlink situation.
Yeah, no problem, I've been a bit overwhelmed too...
Is the application specifically reading the symlink, or is it just using GetFinalPathNameByHandle() and getting the realpath? (which IIRC that function does give the realpath, cf. a20d8bda3). Not that it matters; the application is broken either way. Unfortunately this seems difficult to work around without aggressively trying to hide symlinks.
I didn't get around to my test this weekend, but when I get a chance I'll check both this and what happens in the same situation on Windows.
Problem is, we are going to run into more broken applications like this. Some symlink issues are easy enough to work around, but some like this are harder. But when I think about what would be necessary to really completely hide Unix directory symlinks, it just ends up feeling hacky one way or another; I can see it easily becoming an unmaintainable pile of workarounds. Maybe I'm being too paranoid, though...
Yeah, that's one of the reasons why I think it might be easier to hide unix symlinks rather than to treat them as Windows symlinks. Hiding them is _much_ easier than supporting them properly. As the patches stand, there's only "two" places that need to care: 1) server/fd.c: open_fd() would need to ignore FILE_OPEN_REPARSE_POINT on unix symlinks (any symlink with invalid reparse tag magic) 2) dlls/ntdll/unix/file.c get_file_info() and fd_get_file_info() would need to not report FILE_ATTRIBUTE_REPARSE_POINT for unix symlinks
The only other thing that might be required, which is not difficult, would be to _not_ use the realpath() server/fd.c for regular unix symlinks and use a "normalized" path instead.
Sucks, but the best answer may be "you broke the application, you get to pick up the pieces" :-(
Yeah, if we try to report unix symlinks "properly" that is a very distinct possibility.
(In reply to Arnaud Dovi from comment #38)
If you prefer guy I will do another ticket to better track the other issue
The original issue here should be fixed by staging commit 750044c08c49c7a117fcc911506a198969379144, so yeah - we should probably open a new issue.