How to fix error: unable to create file 'very/long/path/.../file.txt': Filename too long in Git

GitBEGINNERMEDIUM

This error occurs when Git attempts to create a file with a path exceeding Windows' 260-character MAX_PATH limit. Fix it by enabling Git's core.longpaths setting and optionally enabling Windows long path support at the system level.

What this error means

The "unable to create file: Filename too long" error indicates that Git cannot create a file because its full path exceeds the maximum path length allowed by Windows. By default, Windows limits file paths to 260 characters (known as MAX_PATH). This is a Windows-specific limitation inherited from the original Windows API design. The 260-character limit includes: - The drive letter (e.g., `C`) - The colon and backslash (`:\`) - The directory path - The filename - A null terminator character When you clone a repository created on Linux or macOS (which support paths up to 4,096 characters), or when a repository contains deeply nested directories like `node_modules`, the combined path length can easily exceed this Windows limit. Git itself can handle long paths, but it must be explicitly configured to use Windows' extended-length path APIs. Without this configuration, Git uses legacy Windows functions that enforce the 260-character restriction.

How to fix "error: unable to create file 'very/long/path/.../file.txt': Filename too long"

1Enable Git's long path support globally

The primary fix is to configure Git to handle long paths using the Windows extended-length path APIs:

bash

git config --global core.longpaths true

This setting tells Git to use the \\?\\C:\\... path prefix format internally, which supports paths up to approximately 32,767 characters.

Verify the setting is applied:

bash

git config --global --get core.longpaths

This should return true.

For a single repository only:

bash

cd /path/to/repo
git config core.longpaths true

Important: Run this command in an elevated terminal (Administrator) if you encounter permission issues when cloning system-wide.

2Re-clone or reset the repository after enabling long paths

After enabling core.longpaths, you need to restore the files that failed to create:

Option 1: Reset the existing repository

bash

git reset --hard HEAD

Option 2: Re-clone the repository
If the repository is severely affected or reset doesn't work:

bash

# Rename the broken clone
mv my-project my-project-backup

# Clone fresh with long paths already enabled
git clone https://github.com/user/repo.git my-project

# Verify all files are present
cd my-project
git status

Verify success:

bash

git status

If no files show as unexpectedly deleted or modified, the fix worked.

3Enable Windows long path support at the system level

For a more comprehensive fix on Windows 10 (version 1607+) and Windows 11, enable system-wide long path support:

Method 1: Group Policy Editor (Windows 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
5. Restart your computer

Method 2: Registry Editor (All Windows editions)
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
5. Restart your computer

Method 3: PowerShell (as Administrator)

powershell

New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem" -Name "LongPathsEnabled" -Value 1 -PropertyType DWORD -Force

Note: This system setting helps other applications besides Git, but not all Windows applications support long paths even with this enabled.

4Clone into a shorter base directory

If you cannot modify system settings, reduce the base path length to give more room for long paths in the repository:

Instead of:

bash

C:\Users\YourUsername\Documents\Projects\Company\Frontend\my-project

Use a shorter path:

bash

C:\Dev\my-project

Steps:

cmd

mkdir C:\Dev
cd C:\Dev
git clone https://github.com/user/repo.git

Using SUBST to create a virtual drive:
If you need to keep projects in a specific location, create a virtual drive letter pointing to it:

cmd

subst X: "C:\Users\YourUsername\Documents\Projects"
X:
git clone https://github.com/user/repo.git my-project

This makes C:\Users\YourUsername\Documents\Projects\my-project\deep\path\file.txt accessible as X:\my-project\deep\path\file.txt, saving many characters.

5Use sparse-checkout to avoid problematic paths

If you only need specific directories from a repository with problematic long paths, use Git's sparse-checkout feature:

bash

# Clone without checking out files
git clone --filter=blob:none --sparse https://github.com/user/repo.git
cd repo

# Enable cone mode for simpler pattern matching
git sparse-checkout init --cone

# Select only the directories you need
git sparse-checkout set src lib config

This downloads only the selected directories, avoiding the deeply nested paths that cause problems.

To add more directories later:

bash

git sparse-checkout add docs tests

To see current sparse-checkout configuration:

bash

git sparse-checkout list

To disable sparse-checkout and get everything:

bash

git sparse-checkout disable

Note: Make sure core.longpaths is enabled before disabling sparse-checkout if the repository has long paths.

6Handle node_modules and dependency directories

JavaScript projects with node_modules are notorious for creating deeply nested paths. Here are specific solutions:

Ensure node_modules is not tracked by Git:

bash

echo "node_modules/" >> .gitignore
git rm -r --cached node_modules 2>/dev/null
git commit -m "Remove node_modules from tracking"

Use pnpm instead of npm:
pnpm uses a content-addressable store with symlinks, dramatically reducing path lengths:

bash

npm install -g pnpm
pnpm install

Use Yarn with Plug'n'Play:
Yarn's PnP mode eliminates node_modules entirely:

bash

yarn set version berry
yarn config set nodeLinker pnp
yarn install

Flatten npm dependencies:

bash

npm dedupe

If someone accidentally committed node_modules to the repository, the maintainers should remove it from Git history using git-filter-repo or BFG Repo-Cleaner.

7Configure Git for Windows Subsystem for Linux (WSL)

If you frequently encounter path length issues, consider using WSL for Git operations:

Install WSL:

powershell

wsl --install

Clone repositories inside WSL's filesystem:

bash

# Inside WSL terminal
cd ~
git clone https://github.com/user/repo.git

Repositories stored in WSL's native filesystem (/home/username/...) use Linux path limits (4,096+ characters).

Important caveats:
- Accessing WSL files from Windows (via \\wsl$\...) still has Windows path limits
- Keep the repository inside WSL for full long path support
- Use VS Code's Remote - WSL extension for development

Configure Git inside WSL:

bash

git config --global user.name "Your Name"
git config --global user.email "[email protected]"

Advanced notes

### Understanding the Windows MAX_PATH Limit

The 260-character limit breaks down as:
- Drive letter: 1 character (C)
- Colon: 1 character
- Separator: 1 character (\)
- Path: up to 256 characters
- Null terminator: 1 character

The actual usable path is 256 characters including the trailing backslash.

### Extended-Length Path Prefix

Windows has always supported paths up to 32,767 characters using the \\?\\C:\\ prefix. When core.longpaths is enabled, Git uses this extended format internally.

### Git for Windows and MSYS2

Git for Windows uses MSYS2 for its bash environment. MSYS2 has its own path translation layer that can sometimes cause issues even with core.longpaths enabled:

bash

# Force Windows-native path format if MSYS2 translation causes issues
git clone https://github.com/user/repo.git "C:\Dev\repo"

### CI/CD Pipeline Configuration

GitHub Actions:

yaml

- name: Enable long paths
  run: git config --system core.longpaths true

- name: Checkout
  uses: actions/checkout@v4

Azure DevOps:

yaml

steps:
  - checkout: self
  - script: git config core.longpaths true

Jenkins (Windows agent):

groovy

bat 'git config --global core.longpaths true'

### Finding Long Paths in a Repository

Before cloning, check for potential issues:

powershell

# In PowerShell, find paths approaching the limit
Get-ChildItem -Recurse | Where-Object { $_.FullName.Length -gt 200 } |
  Select-Object @{N='Length';E={$_.FullName.Length}}, FullName |
  Sort-Object Length -Descending | Select-Object -First 20

### Pre-commit Hook for Path Length Checks

Add a hook to prevent committing files with paths that would cause issues on Windows:

bash

#!/bin/bash
# .git/hooks/pre-commit
MAX_PATH=260
BASE_PATH_LENGTH=30  # Account for clone location

git diff --cached --name-only | while read file; do
  path_length=$((BASE_PATH_LENGTH + ${#file}))
  if [ $path_length -gt $MAX_PATH ]; then
    echo "ERROR: Path too long for Windows: $file ($path_length chars)"
    exit 1
  fi
done

### Third-Party Tool Compatibility

Even with all Git settings configured, some tools may fail:
- Older versions of Windows Explorer
- Some IDEs and editors
- Build tools using legacy Windows APIs
- Antivirus software scanning files

Test your complete development toolchain when working with repositories known to have long paths.

### Related Configuration

bash

# Check all path-related Git settings
git config --global -l | grep -i path

# Other potentially relevant settings
git config --global core.protectNTFS true  # Protect against malicious paths
git config --global core.fscache true       # Speed up status on Windows

How to fix error: unable to create file 'very/long/path/.../file.txt': Filename too long in Git

What this error means

Typical symptoms

Common causes

How to fix "error: unable to create file 'very/long/path/.../file.txt': Filename too long"

Advanced notes

Related errors

Official resources & further reading