https://bugs.winehq.org/show_bug.cgi?id=50586
--- Comment #43 from Erich E. Hoover erich.e.hoover@gmail.com --- (In reply to Zebediah Figura from comment #42)
... I think not using realpath() is absolutely required. We'd still have to manually resolve the real path for non-Unix symlinks, though.
For NT symlinks I'm currently storing both the original/symlink path (non-normalized) and the realpath(), if you're saying that the original/symlink path needs to be normalized then I should probably add that to the current patches.
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:
We can easily do the same fake-out that we're doing right now with FileAttributeTagInformation returning IO_REPARSE_TAG_MOUNT_POINT. It's possible here that there are applications that would be broken by this (but they would be just as broken now), but worst case this could be replaced with a wine-specific option or FILE_INFORMATION_CLASS.
- 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?
Not unless we have to, since right now Wine doesn't do this with unix symlinks and nobody seems to notice.
- 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.
Since Wine doesn't do this right now, I would not suggest that an initial implementation do it either.
- 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?
I really don't think we should pretend there's only one file system.
Maybe there's an argument for hiding host symlinks only in the same-device case.
I think there's a decent argument that we could start from the current Wine position (hiding) and add complexity if it proves to be a problem.
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...
Yeah, I think we are likely to find more issues now that we've started reporting unix symlinks as NT symlinks (especially since Wine creates symlinks for My Documents, Desktop, and Downloads). Before we only had the possibility of applications seeing NT symlinks from Windows applications that actually created them in the first place. I'd be happy to be wrong though, code-wise reporting unix symlinks as NT symlinks is easier than hiding them ;)