1

For a java app I'm working we store some Ubuntu fonts in our git repository. Keep in mind, this all works as expected for other devs on other machines with a similar setup.

This issue occurs only using WSL Git and not Git for Windows/Git Bash (gitforwindows.org).

Windows (specifically System32/fontview.exe), and our application for that matter, cannot open/load these font files when they're in a git repo.

The requested file ... is not a valid font file.

mving that same file to any location outside of a Git repository, Windows is able to open the file. The file is the same (checked using sha1sum < fontfile.ttf).

The same error is also thrown when copying that file into a newly initialized Git repository.

This is true for all ttf files, even if they're newly downloaded from the web.

Even after rm -rf .git the files still cannot be opened/loaded. That specific directory name somehow becomes permanently affected.

The problem persists after a reboot.

Marius Schär
  • 113
  • 5
  • Does this happen with any git repository? Are you able to open them from the same folder before you create a git in it? – Seth Apr 03 '19 at 13:01
  • 1
    @Seth any repo, even newly `git init`ed ones. They're find in the same folder before repo creation. – Marius Schär Apr 03 '19 at 13:32
  • @Seth I've been able to narrow it down to NTFS. I don't have these problems on a drive that's formatted FAT32. – Marius Schär Apr 08 '19 at 15:16
  • What does all that have to do with WSL? Running git straight from Windows works fine? – Seth Apr 09 '19 at 05:15
  • @Seth My Org recommends we use C:\work\ for our repos and workspaces. I've now created a C:\work2\ and checked out the repo once from WSL and once from Git for Windows. Git for Windows works fine, WSL does not. So it has something to do with it... – Marius Schär Apr 09 '19 at 06:51
  • Have a look at file before and after. Maybe it has something to do with either special properties (file system level) that are added or for some reason line endings (if they contain them) gets changed? – Seth Apr 09 '19 at 08:41
  • 1
    @Seth I used the commands from [this SU post](https://superuser.com/questions/898017/windows-command-to-get-all-information-properties-of-a-file) to look at the file attributes. The one that works looks like I'd expect, the other only has a value for `Name`, all the other attributes seem to be empty. – Marius Schär Apr 09 '19 at 11:50

1 Answers1

0

We are told that although accessing Windows files from WSL is OK (via /mnt/c , /mnt/d etc ), doing it the other way round, is not supported, due to the way the Linux filesystem is emulated (?) in Windows.

Hence you should copy your files to a location back in the Windows environment proper (eg. /mnt/c/Users/joebloggs/workspace ....), before trying to access them with Windows-based tools.

However, things might change, this new functionality will allow you to access the Linux filesystem like a network drive:

https://betanews.com/2019/02/16/access-linux-files-from-windows/

If you just want to run git in Windows, use "Git for Windows" without WSL ! eg https://git-scm.com/download/win

MikeW
  • 148
  • 6
  • Is it already known if this limitation will still exist with the new WSL Microsoft announced recently? – Marius Schär May 16 '19 at 08:03
  • I would expect it to still be there, due to the way the subsystems need to interact. I export things back to the Windows /mnt/c if I need to. Hope this is worthy of an Answer ;-) – MikeW May 16 '19 at 08:27
  • Update: see the extra info in the answer. You will be able to access the Linux filesystem like a network drive. – MikeW May 17 '19 at 08:51