"error: invalid path" during git clone to Windows client
Platform Notice: Cloud, Server, and Data Center - This article applies equally to all platforms.
Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Summary
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.
Environment
Windows
Diagnosis
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.
Cause
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
Solution
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 falseTurning 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.