%20Git%20%E3%83%AA%E3%83%9D%E3%82%B8%E3%83%88%E3%83%AA%E5%86%85%E3%81%AE%20.ttf%20%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%82%92%E9%96%8B%E3%81%8F%E3%81%93%E3%81%A8%E3%81%8C%E3%81%A7%E3%81%8D%E3%81%BE%E3%81%9B%E3%82%93.png)
私が取り組んでいる Java アプリでは、Ubuntu フォントの一部を Git リポジトリに保存しています。同様の設定を持つ他のマシンの他の開発者にとっても、これはすべて期待どおりに機能することを覚えておいてください。
この問題は、WSL Git を使用した場合にのみ発生し、Git for Windows/Git Bash (gitforwindows.org) では発生しません。
Windows (具体的には System32/fontview.exe)、そして私たちのアプリケーションは、これらのフォント ファイルが git リポジトリにある場合、それを開いたり読み込んだりすることができません。
要求されたファイル...は有効なフォント ファイルではありません。
mv
同じファイルを Git リポジトリの外部の任意の場所にコピーすると、Windows でファイルを開くことができます。ファイルは同じです ( を使用して確認済みsha1sum < fontfile.ttf
)。
そのファイルを新しく初期化された Git リポジトリにコピーするときにも、同じエラーがスローされます。
これは、Web から新しくダウンロードした場合でも、すべての ttf ファイルに当てはまります。
その後も、rm -rf .git
ファイルを開いたり読み込んだりすることはできません。その特定のディレクトリ名は、何らかの理由で永続的に影響を受けます。
再起動後も問題は解決しません。
答え1
WSL から Windows ファイルにアクセスすることは ( /mnt/c 、 /mnt/d などを介して) 問題ありませんが、その逆は、Linux ファイルシステムが Windows でエミュレートされる方法 (?) のため、サポートされていないと言われています。
したがって、Windows ベースのツールでファイルにアクセスする前に、ファイルを Windows 環境内の適切な場所 (例: /mnt/c/Users/joebloggs/workspace ....) にコピーする必要があります。
ただし、状況は変わる可能性があります。この新しい機能により、ネットワーク ドライブのように Linux ファイルシステムにアクセスできるようになります。
https://betanews.com/2019/02/16/access-linux-files-from-windows/
Windowsでgitを実行したいだけの場合は、WSLなしで「Git for Windows」を使用してください。例:https://git-scm.com/download/win