You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In my environment, this failure occurred after upgrading to the latest cygwin DLL (from 2.54 or something). My cygwin dir was like "D:\Cygwin64", but wslbridge was trying to invoke "/mnt/d/cygwin64/usr/local/bin/wslbridge-backend", which was failing due to case difference of the path.
(After I have renamed Cygwin64 to cygwin64, wslbridge could successfully load backend again)
It seems that GetModuleFileNameW() isn't guaranteed to preserve case of the path name. It seems to depend on how the executable was kicked, which probably has been changed in the recent Cygwin update.
The text was updated successfully, but these errors were encountered:
GetFinalPathNameByHandle normalizes case and resolves symlinks and junctions. WSL cannot see either Windows symlinks or junctions. Hard links are transparent through Windows, Cygwin, and WSL. (i.e. After I use mklink /h on a file, stat shows Links: 2 in both Cygwin and WSL.)
GetFinalPathNameByHandle also resolves subst drives. If I mount an NTFS volume into both a drive letter and an empty directory on some drive, then GetFinalPathNameByHandle seems to always prefer the drive letter. If I mount an NTFS volume solely on an empty directory, then GetFinalPathNameByHandle returns the mount path (there's no other option...), which WSL is unable to access.
AFAICT, it isn't possible to do any better than what GetFinalPathNameByHandle does.
I also tested GetFullPathName and PathCanonicalize, which did not canonicalize case or resolve symlinks.
So, once the frontend locates the backend (and can open a HANDLE to it), it'll use GetFinalPathNameByHandle to get a normalized path. The remaining question is whether the frontend should change how it locates the backend (e.g. I can't remember whether it should resolve symlinks in the parent directory before or after looking for the backend). I suppose wslbridge does the same thing as winpty, and no one has ever complained about that, so it's probably OK.
In my environment, this failure occurred after upgrading to the latest cygwin DLL (from 2.54 or something). My cygwin dir was like "D:\Cygwin64", but wslbridge was trying to invoke "/mnt/d/cygwin64/usr/local/bin/wslbridge-backend", which was failing due to case difference of the path.
(After I have renamed Cygwin64 to cygwin64, wslbridge could successfully load backend again)
It seems that GetModuleFileNameW() isn't guaranteed to preserve case of the path name. It seems to depend on how the executable was kicked, which probably has been changed in the recent Cygwin update.
The text was updated successfully, but these errors were encountered: