"error: invalid path" during git clone to Windows client
プラットフォームについて: Cloud、Server、および Data Center - この記事はすべてのプラットフォームに適用されます。
The Git cloning of repository succeeds on a Linux client but fails on a Windows client with an "invalid path" error. Windows OS reserves some filenames, hence a file name may be legal in Linux but illegal in Windows.
The error will manifest during the final checkout during a git clone/fetch. As an example we try to clone a repository that contains the
$ git clone --progress --verbose ssh://email@example.com:7999/project/myrepo.git Cloning into 'myrepo'... remote: Enumerating objects: 825542, done. remote: Counting objects: 100% (825542/825542), done. remote: Compressing objects: 100% (239771/239771), done. remote: Total 1414136 (delta 769602), reused 586108 (delta 585739), pack-reused 588594 Receiving objects: 100% (1414136/1414136), 13.91 GiB | 22.80 MiB/s, done. Resolving deltas: 100% (1132339/1132339), done. error: invalid path 'path/to/broken/file/con.h' fatal: unable to checkout working tree warning: Clone succeeded, but checkout failed. You can inspect what was checked out with 'git status' and retry with 'git restore --source=HEAD :/'
Nothing appears to be wrong with the path. The issue is that the base name of the file is
con which is a reserved name in Windows.
Windows reserves certain file names so trying to create a file that uses a reserved base name should fail.
Please refer to the Naming a file Windows documentation:
Do not use the following reserved names for the name of a file:
CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, and LPT9. Also avoid these names followed immediately by an extension; for example, NUL.txt is not recommended
Whilst this may workaround the issue, care should be taken as the default for a Windows client was set to
core.protectNTFS=true to close a potential security issue
CVE-2019-1353 as described here.
Depending on the filename, configuring Git to ignore NTFS naming may workaround the issue.
git config --global core.protectNTFS false
protectNTFS will stop Git from complaining about files that have a base name that is reserved but will not prevent an error if the filename is one of the reserved names.
The only workaround is to rename any offending file(s) at the source repository or via a non-Windows client.