search

andy-5 / wslgit

Use Git installed in Bash on Windows/Windows Subsystem for Linux (WSL) from Windows and Visual Studio Code (VSCode)
MIT License
1.18k stars 59 forks source link

wslgit doesn't work when current working directory is a network drive #50

Closed diablodale closed 5 years ago

diablodale commented 5 years ago

WSLgit doesn't work when current working directory is a network drive.

When developing server solutions, I often want to have my files and git repository on a network location that is shared by both the client (my editor) and server. My first approach to this is a shared SMB/CIFS network drive.

This issue is somewhat related to https://github.com/andy-5/wslgit/issues/12

Setup

Windows 10 Pro, ver 1809, build 17763.1 WSL is Ubuntu 16.04.5 LTS Git for Windows installed WSLGit v0.6.0 installed An SMB/CIFS server on your local network

Repo

  1. At CMD prompt: net use n: \\myserver\myshare
  2. Create a test directory on your N: drive, e.g. N:\test1
  3. Inside that N:\test1 directory create a new git repo with git init
  4. In WSL: edit /etc/fstab and add an entry to mount that N: drive. For example: 
    N:  /mnt/n  drvfs  rw,noatime,uid=1000,gid=1000,fmask=0027,dmask=0027,_netdev,nofail  0 0
  5. mkdir /mnt/n
  6. Mount the new n drive with something like sudo mount -a
  7. Verify your N: share is now visible at /mnt/n
  8. cd /mnt/n/test1
  9. Verify the git repo is valid with git status
  10. At CMD prompt: change your current drive and working directory to N:\test1
  11. Run wslgit.exe status

Result

Error, e.g.: fatal: Not a git repository (or any of the parent directories): .git

Expected

Valid git status result, e.g.:

On branch master
Initial commit...

Cause of failure

The current WSL infrastructure and WSLgit do not robustly lookup/manage the mapping of drive letters to WSL mount points. This has been explored in other issues. Currently, WSL does successfully map the simple automap of fixed local drives to mountpoints located in /mnt/driveletter. It explicitly does not map network drives. When WSLgit calls wsl xxxxxx, the WSL infrastructure can not map the current working directory of N:\test1 to a WSL mountpoint since that is a network drive. Therefore, the WSL infrastructure makes the WSL current working directory the WSL user's home directory. Naturally, this will not work as git is now trying to get a status in a completely different directory.

Proposed Fix

I propose that WSLgit always changes directory before running git. WSLgit already assumes that if there is a DOS drive letter, that it is mounted at /mnt/driveletter. We can use this assumption to cd. Note: drive letters that are not mounted to /mnt/driveletter are already not supported as discussed in other issues.

I considered only doing this cd on network drives. However, deriving what is a local fixed drive that can be mapped vs. a network drive vs. automounted drive is too complex when all we need is a very fast and simple cd.

I did check and the behavior of wslpath. Unfortunately, it seems to use a shared logic as the automatic WSL current working directory mapping. It is unable to derive the WSL mountpoint for a network drive.

I have a small code fix that I have used for several days. It is working well on both local drives and network drives. I will send a PR with it for discussion.

Comment

During my testing, I did encounter a error Transport endpoint is not connected when git was used on directories with names like tößhalloëÖfz. This was not a problem with WSL or WSLgit. Instead, the SMB/CIFS server was not correctly mapping characters between SMB protocol's UTF-16 and the (Linux) server's native UTF-8. This was because the default locales install on my Linux server didn't include the full UTF-8 locale and instead had only the limited POSIX and C.UTF8. The fix was a server-only fix to install a full UTF-8 locale like en_US.UTF-8 and ensure my server processes know to use that locale. Here is how I did that on an Ubuntu 18.04 server.

locale-gen en_US.UTF-8
update-locale LANG=en_US.UTF-8
export LANG=en_US.UTF-8
andy-5 commented 5 years ago

Thanks for this detailed overview and for your patch.

Your PR looks fine and I will merge it shortly. The only thing that could maybe be improved is to print an error if the current path is not a valid unicode string. But that is a minor issue, as such paths are not supported anyway (translate_path_to_unix prints an error in that case) and I'm not sure if such paths can even exist on Windows.