https://bugs.winehq.org/show_bug.cgi?id=50586
--- Comment #16 from Erich E. Hoover erich.e.hoover@gmail.com --- (In reply to Zebediah Figura from comment #15)
(In reply to Hans Leidekker from comment #14)
... If cross-device *directory* unix symlinks where NT symlinks but not cross-device *file* unix symlinks then I think you could end up with inconsistencies. E.g. GetVolumePathName would report different volumes for a file and its parent directory if the file is a symlink to a third filesystem.
I'm not sure I understand. If we pretend that cross-device file symlinks aren't symlinks, then a file will always report the same device as its containing directory, won't it? ...
If I'm understanding correctly, we're talking about (in the context of unix symlinks): 1) 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?