What causes "ENAMETOOLONG"?

Windows MAX_PATH limit of 260 characters is exceeded by the full file path Git's core.longpaths setting is not enabled (default is false) Repository was created on Linux/macOS where path limits are much higher (4096+ chars)

Is the "ENAMETOOLONG" error serious?

It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

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

GitBEGINNERMEDIUMUpdated Dec 6, 2025· 377 views

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.

Quick fix

Fixes ENAMETOOLONG

git config --global core.longpaths true

Enable Git's long path support globally
Re-clone or reset the repository after enabling long paths
Enable Windows long path support at the system level
Clone into a shorter base directory

git — error

$git config --global core.longpaths true
error: unable to create file 'very/long/path/.../file.txt': Filename too long

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.

Typical symptoms

Git clone fails with 'error: unable to create file ... Filename too long'
Git checkout fails when switching to branches with deeply nested files
Git pull reports errors for specific files with long paths
Repository clones but appears to have missing files
Git status shows files as deleted that shouldn't be
Git reset --hard fails to restore certain files
Node.js projects with node_modules fail to clone completely
Java/Maven projects with long package names encounter issues
Monorepos with deeply nested directory structures fail partially

Common causes

Windows MAX_PATH limit of 260 characters is exceeded by the full file path
Git's core.longpaths setting is not enabled (default is false)
Repository was created on Linux/macOS where path limits are much higher (4096+ chars)
Deeply nested directory structures (especially node_modules in JavaScript projects)
Long filenames combined with deep directory nesting
Cloning into a directory with an already long base path
Windows system-level long path support is not enabled
Using Git Bash or MinGW which may have additional path translation issues

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 "your@email.com"

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

Frequently asked questions

What does "ENAMETOOLONG" mean?: 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.
How do I fix "ENAMETOOLONG"?: 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 causes "ENAMETOOLONG"?: Windows MAX_PATH limit of 260 characters is exceeded by the full file path Git's core.longpaths setting is not enabled (default is false) Repository was created on Linux/macOS where path limits are much higher (4096+ chars)
Is the "ENAMETOOLONG" error serious?: It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading

📚Git Official Documentation
📖
Git Documentation - core.longpaths(Official Docs)
📖
Microsoft Docs - Maximum Path Length Limitation(Official Docs)
📖
Microsoft Docs - Enable Long Paths in Windows 10(Official Docs)
🐙
Git for Windows Wiki - Long Paths(GitHub)
💬
Stack Overflow - Filename too long in Git for Windows(Stack Overflow)

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

Quick fix

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

Frequently asked questions

Related errors

Official resources & further reading