How to fix fatal: cannot create directory: Filename too long. Enable long paths with git config --global core.longpaths true in Git

GitBEGINNERMEDIUMUpdated Dec 6, 2025· 320 views

This error occurs on Windows when Git tries to create files with paths exceeding the 260-character limit. Windows historically restricts path lengths to 260 characters (MAX_PATH), but this can be resolved by enabling Git's core.longpaths setting and optionally enabling Windows long path support.

Quick fix

Fixes fatal: cannot create directory: Filename too long. Enable long paths with git config --global core.longpaths true

git config --global core.longpaths true
  1. Enable core.longpaths in Git globally
  2. Enable core.longpaths system-wide (requires admin)
  3. Enable long paths during clone
  4. Enable Windows long path support (Windows 10 1607+)
git — error
git config --global core.longpaths true
fatal: cannot create directory: Filename too long. Enable long paths with git config --global core.longpaths true

What this error means

The "fatal: cannot create directory: Filename too long" error occurs because Windows has a historical 260-character limit on file paths, known as the MAX_PATH limitation. This restriction is baked into the Windows API and affects most applications, including Git for Windows. When you clone a repository or check out a branch with deeply nested directory structures or long filenames, Git may fail to create the necessary files because the full path exceeds this limit. This is particularly common with: - **Node.js projects** with deeply nested `node_modules` folders - **Java/Maven projects** with long package names and nested dependencies - **Monorepos** with complex directory hierarchies - **Repositories cloned into already-deep directory paths** (e.g., `C:\Users\YourName\Documents\Projects\Company\Department\Team\Project`) The `core.longpaths` setting tells Git to use the Windows extended-length path prefix (`\\?\\...`) internally, which allows paths up to approximately 32,767 characters. However, this requires both Git configuration and potentially Windows-level settings to work reliably.

Typical symptoms

  • Git clone fails with 'fatal: cannot create directory: Filename too long'
  • Git checkout fails when switching to branches with deeply nested files
  • Git pull fails partway through when new files have long paths
  • The error appears on Windows but not on macOS or Linux
  • The same repository clones successfully in a shorter directory path
  • CI/CD pipelines on Windows runners fail while Linux runners succeed
  • npm/yarn install creates deeply nested node_modules that Git cannot track

Common causes

  1. The repository contains files with paths exceeding Windows' 260-character MAX_PATH limit
  2. Git's core.longpaths setting is not enabled (disabled by default)
  3. Windows long path support is not enabled at the OS level (Windows 10 1607+)
  4. The repository is cloned into an already-deep directory path, reducing available path length
  5. Node.js projects with deeply nested node_modules dependencies
  6. Java or .NET projects with long package/namespace hierarchies
  7. The repository was created on Linux/macOS where path limits are much higher (4096+ chars)
  8. Monorepo structures with multiple levels of project nesting

How to fix "fatal: cannot create directory: Filename too long. Enable long paths with git config --global core.longpaths true"

1Enable core.longpaths in Git globally

The quickest fix is to enable Git's long path support. This tells Git to use Windows extended-length paths:

bash
git config --global core.longpaths true

This applies the setting for all repositories for your user account. No administrator privileges required.

Verify the setting:

bash
git config --global --get core.longpaths
# Should output: true

After enabling, retry your clone or checkout:

bash
git clone <repository-url>
# or
git checkout <branch-name>
2Enable core.longpaths system-wide (requires admin)

If you want long paths enabled for all users on the machine, use the system-level configuration. This requires administrator privileges:

Option 1: Run Git Bash as Administrator

bash
git config --system core.longpaths true

Option 2: Run Command Prompt as Administrator

cmd
git config --system core.longpaths true

Option 3: Run PowerShell as Administrator

powershell
git config --system core.longpaths true

This modifies the Git system configuration file (typically C:\Program Files\Git\etc\gitconfig).

Note: If you get "error: could not lock config file", you need to run as Administrator.

3Enable long paths during clone

If you prefer not to change your global settings, you can enable long paths for a single clone operation:

bash
git clone -c core.longpaths=true <repository-url>

This passes the configuration as a command-line option, applying it only for this operation and the resulting repository.

For an existing repository that failed mid-clone:
1. Delete the partially cloned folder
2. Re-run the clone with the -c option
3. Or add the setting to the existing repo:

bash
cd <repo-folder>
git config core.longpaths true
git checkout .
4Enable Windows long path support (Windows 10 1607+)

For comprehensive long path support, enable it at the Windows operating system level. This requires Windows 10 version 1607 (Anniversary Update) or later.

Option 1: PowerShell (as Administrator)

powershell
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem" -Name "LongPathsEnabled" -Value 1 -Type DWord

Option 2: Registry Editor (regedit)
1. Press Win+R, type regedit, press Enter
2. Navigate to: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem
3. Find or create a DWORD value named LongPathsEnabled
4. Set its value to 1

Option 3: Group Policy (Windows 10 Pro/Enterprise)
1. Press Win+R, type gpedit.msc, press Enter
2. Navigate to: Computer Configuration > Administrative Templates > System > Filesystem
3. Double-click "Enable Win32 long paths"
4. Select "Enabled" and click OK

Important: Restart your computer after making this change.

This enables long path support for all applications that opt in, not just Git.

5Clone to a shorter base path

If you cannot enable long paths (e.g., corporate restrictions), reduce the total path length by cloning to a shorter base path:

Instead of:

bash
C:\Users\YourName\Documents\Projects\Company\Department\Project

Use:

bash
# Create a short path close to root
mkdir C:\dev
cd C:\dev
git clone <repository-url>

Or use a drive letter substitute:

cmd
# Create a virtual drive letter for a long path
subst X: "C:\Users\YourName\Documents\Projects"
cd X:
git clone <repository-url>

This effectively shortens the base path, leaving more characters available for file paths within the repository.

6Fix partial clones or corrupted checkouts

If the clone or checkout failed partway through, you may have a corrupted working directory. Here's how to recover:

For failed clones:

bash
# Remove the partial clone
rm -rf <repo-folder>

# Enable long paths first
git config --global core.longpaths true

# Clone again
git clone <repository-url>

For existing repositories with checkout issues:

bash
# Enable long paths for this repo
cd <repo-folder>
git config core.longpaths true

# Reset the working directory
git reset --hard HEAD

# If files are still missing, force checkout
git checkout -f HEAD

For stubborn cases:

bash
# Clear the working directory and re-checkout
git clean -fdx
git checkout -f HEAD

Warning: git clean -fdx removes all untracked files including ignored files. Make sure you don't have uncommitted work you want to keep.

7Use Windows Subsystem for Linux (WSL)

If long path issues persist or you frequently work with repositories that have path length problems, consider using WSL:

Install WSL (Windows 10/11):

powershell
# Run as Administrator
wsl --install

Clone within WSL:

bash
# In WSL terminal
cd ~
git clone <repository-url>

WSL uses the Linux filesystem, which supports paths up to 4096 characters by default. This completely bypasses Windows path length restrictions.

Accessing WSL files from Windows:
- From Windows Explorer: \\wsl$\Ubuntu\home\<username>\<repo>
- From VS Code: Install the "Remote - WSL" extension

Note: For best performance, keep repositories within the WSL filesystem (/home/...) rather than accessing Windows drives (/mnt/c/...) from WSL.

Advanced notes

Understanding Windows MAX_PATH:

The 260-character limit comes from the Windows API definition:

bash
MAX_PATH = 260  // includes drive, path, filename, and null terminator

This means the actual usable path is 259 characters. This limit dates back to MS-DOS and Windows 95 compatibility requirements.

How core.longpaths Works:

When core.longpaths is enabled, Git for Windows uses the extended-length path prefix (\\?\\C:\\...) when calling Windows APIs. This tells Windows to bypass the MAX_PATH check and allow paths up to 32,767 characters.

However, this prefix has limitations:
- The path must be absolute (no relative paths)
- Forward slashes must be converted to backslashes
- Path normalization (removing . and ..) must be done by the application
- Some Windows applications and shell commands don't support these paths

Why core.longpaths Is Disabled by Default:

Git keeps this setting disabled by default because:
1. Compatibility: Some Windows tools (including older IDEs and file managers) cannot handle long paths
2. Predictability: Repositories that work on one Windows machine might not work on another without the setting
3. Cross-platform concerns: Files created on Windows with long paths might not be accessible by Windows tools

Git GUIs and IDEs:

Some Git GUIs may need additional configuration:
- GitHub Desktop: Respects --global but not always --system
- SourceTree: May use embedded Git; ensure it uses system Git
- VS Code: Uses system Git; should work with global setting
- JetBrains IDEs: Uses system Git; should work with global setting

CI/CD Considerations:

For Windows-based CI/CD runners:

yaml
# GitHub Actions example
- name: Enable Git long paths
  run: git config --system core.longpaths true
  shell: cmd

Or set during checkout:

yaml
- uses: actions/checkout@v4
  with:
    fetch-depth: 0
- name: Configure Git
  run: git config core.longpaths true

Preventing the Issue:

If you maintain a repository that might be cloned on Windows:
1. Avoid deeply nested directory structures
2. Keep file and folder names short
3. Document the core.longpaths requirement in README
4. Consider a .gitattributes hint (though Git doesn't auto-configure based on this)
5. For Node.js, consider using npm dedupe or yarn's hoisting to flatten node_modules

The 260 vs 256 Confusion:

You might see references to both 260 and 256 character limits:
- 260 = total path including null terminator
- 256 = practical limit after accounting for drive letter, colon, backslash, and null
- The actual limit varies slightly depending on how the path is constructed

Frequently asked questions

What does "fatal: cannot create directory: Filename too long. Enable long paths w" mean?
The "fatal: cannot create directory: Filename too long" error occurs because Windows has a historical 260-character limit on file paths, known as the MAX_PATH limitation. This restriction is baked into the Windows API and affects most applications, including Git for Windows. When you clone a repository or check out a branch with deeply nested directory structures or long filenames, Git may fail to create the necessary files because the full path exceeds this limit.
How do I fix "fatal: cannot create directory: Filename too long. Enable long paths w"?
This error occurs on Windows when Git tries to create files with paths exceeding the 260-character limit. Windows historically restricts path lengths to 260 characters (MAX_PATH), but this can be resolved by enabling Git's core.longpaths setting and optionally enabling Windows long path support.
What causes "fatal: cannot create directory: Filename too long. Enable long paths w"?
The repository contains files with paths exceeding Windows' 260-character MAX_PATH limit Git's core.longpaths setting is not enabled (disabled by default) Windows long path support is not enabled at the OS level (Windows 10 1607+)
Is the "fatal: cannot create directory: Filename too long. Enable long paths w" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading