"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 con.h filename.

$ git clone --progress --verbose ssh://git@mybb.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

Turning off 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.

最終更新日: 2021 年 10 月 1 日


Powered by Confluence and Scroll Viewport.