Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fails to start backend due to case difference of the path name #4

Closed
nu774 opened this issue Sep 26, 2016 · 3 comments
Closed

Fails to start backend due to case difference of the path name #4

nu774 opened this issue Sep 26, 2016 · 3 comments
Labels

Comments

@nu774
Copy link

nu774 commented Sep 26, 2016

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.

@rprichard
Copy link
Owner

Thanks for the report. I suppose wslbridge needs to normalize its path somehow? I'm not sure off-hand how it'd do that.

@rprichard
Copy link
Owner

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.)

@rprichard
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants