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://[email protected]: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.
