https://bugs.winehq.org/show_bug.cgi?id=50586
--- Comment #42 from Zebediah Figura z.figura12@gmail.com --- (In reply to Erich E. Hoover from comment #41)
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:
- 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.
I think not using realpath() is absolutely required. We'd still have to manually resolve the real path for non-Unix symlinks, though.
But here are the other problems:
* What does GetVolumePathName() on a cross-device Unix symlink return? I'm not even necessarily thinking about file IDs here—we can fit st_dev + st_ino into a 16-byte file ID if we have to—but rather:
* do we report that two files are on the same device when they aren't actually? Would it break an application that suddenly can't cope when renaming the file fails?
* What if you then pass that name to other volume functions? If GetVolumePathName() returns the symlink, how does kernelbase determine the actual mount point? If it returns the C: drive for every file, then we lie to the application about aspects of the file system—say, the amount of free space left.
* If we punt and pretend that there's only ever one file system—what about removable devices? Do we apply a heuristic and always expose cross-device host symlinks to removable devices, but not otherwise?
Maybe there's an argument for hiding host symlinks only in the same-device case. On the other hand, I'm inclined to say that some applications are broken, and in that case the user will just have to work around that by not using symlinks. How many applications are actually affected by such symlink bugs is of course difficult or impossible to guess, but at least we haven't seen *that* many come up yet, not in wine-staging...