https://bugs.winehq.org/show_bug.cgi?id=50586
--- Comment #18 from Zebediah Figura z.figura12@gmail.com --- (In reply to Erich E. Hoover from comment #16)
If I'm understanding correctly, we're talking about (in the context of unix symlinks):
- reporting file symlinks transparently (no evidence to the Windows program
that they exist) 2) reporting file symlinks using the inode number of the symlink rather than the target so that inode searches work correctly 3) reporting directory symlinks as an NT directory symlink (0xA000000C)
So, due to #2 combined with #3, GetVolumePathName will always see that a file symlink is on the same device as the parent directory and if that directory is on a different device than its parent then it may report that directory as the start of the volume. Example: C:\myfolder -> D:\myfolder D:\myfolder\myfile -> E:\myfile GetVolumePathName(C:\myfolder\myfile) would give C:\myfolder, where C:\myfolder reports the target inode on D:\ and C:\myfolder\myfile reports the symlink inode on D:.
If i'm understanding correctly then this sounds reasonable to me, if a little complicated to implement. My inclination would be start by making unix symlinks act as similar as possible to how they do in non-staging now (transparently report all information about the target, regardless of being for a file or a directory) and then add this complexity on from there once I'm sure nothing is broken. How does that sound to everyone?
I think so, yeah. But on the other hand, two questions:
(1) How much of a problem is it really to report Unix symlinks as win32 symlinks? (Does the wine-staging patch already do this?) It could potentially be simpler. Note also that we need to treat system DLLs specially anyway, to get copy-on-write behaviour.
(2) On the other hand, if there is a good reason to hide Unix symlinks, does it make sense to also hide same-device Unix directory symlinks?