How to fix error: cannot create directory 'path': File exists in Git

GitINTERMEDIATEMEDIUM

This Git error occurs during checkout, clone, or pull when Git cannot create a directory because a file or another directory with the same name already exists at that path. Common causes include file/directory name conflicts, Windows path limitations, and case sensitivity issues.

What this error means

This error occurs when Git attempts to create a directory as part of a checkout, clone, or pull operation, but something already exists at that exact path. The conflict prevents Git from completing the operation because it cannot safely overwrite existing files or directories. The most common scenario is a name collision between a file and a directory. For example, if you have a file named `vendor` in your working directory, and the branch you're checking out has a directory called `vendor/`, Git cannot create the directory because the file is blocking it. The reverse can also happen: a directory exists where Git needs to place a file. This error is particularly common when working across different operating systems. On case-insensitive file systems like Windows and macOS (by default), `Vendor` and `vendor` are considered the same name, leading to conflicts that wouldn't occur on Linux. Windows also has additional limitations like reserved file names (CON, PRN, AUX) and path length restrictions that can trigger this error.

How to fix "error: cannot create directory 'path': File exists"

1Identify the conflicting file or directory

First, determine what's blocking Git from creating the directory:

bash

# On Linux/macOS, list all files including hidden ones
ls -la path/to/parent/

# On Windows, show all files
dir /a path\to\parent\

# Check Git status for untracked files
git status

# List what Git expects at that path
git ls-tree HEAD -- path/to/

Compare what exists on disk with what Git is trying to create. Look for:
- A file where Git needs a directory
- A directory where Git needs a file
- Case-sensitivity differences in names

2Close IDEs and editors before retrying

File locks from editors can prevent Git from modifying the file system:

bash

# Close Visual Studio Code, IntelliJ, etc.
# Then retry the Git operation

git checkout feature-branch
# or
git pull origin main

Common applications that lock files:
- Visual Studio Code (especially with extensions)
- IntelliJ IDEA / WebStorm / PyCharm
- Visual Studio
- Windows Explorer (when previewing files)
- Antivirus software scanning files

After closing applications, you may also need to clear Git's state:

bash

# Reset to clean up partial operation state
git reset --hard HEAD

3Remove the conflicting file or directory

If you've identified the conflict, remove or rename the blocking item:

bash

# Remove a conflicting file
rm path/to/conflicting-file

# Or rename it to investigate later
mv path/to/conflicting-file path/to/conflicting-file.backup

# For directories
rm -rf path/to/conflicting-directory
# Or
mv path/to/conflicting-directory path/to/conflicting-directory.backup

Using git clean to remove untracked files:

bash

# Dry run first - see what would be removed
git clean -n

# Remove untracked files
git clean -f

# Remove untracked files AND directories
git clean -fd

# Include ignored files
git clean -fdx

After removing the conflict, retry your Git operation:

bash

git checkout feature-branch

4Fix case sensitivity issues

If the issue is caused by case differences (e.g., Vendor vs vendor):

bash

# Check Git's case sensitivity setting
git config core.ignorecase

# See files with case conflicts
git ls-files | sort -f | uniq -di

On Windows/macOS (case-insensitive):

bash

# Rename to a temporary name, then to correct case
git mv Vendor temp-vendor
git mv temp-vendor vendor
git commit -m "fix: correct directory casing"

# Or force case change on the file system
git rm -r --cached Vendor
git add vendor
git commit -m "fix: normalize directory casing"

To prevent future issues, configure Git:

bash

# Make Git case-sensitive (recommended for cross-platform work)
git config core.ignorecase false

5Fix Windows path length issues

Windows has a 260-character path limit that can cause this error. Enable long path support:

bash

# Enable long paths in Git (Windows)
git config --global core.longpaths true

Enable in Windows (requires admin):

1. Run gpedit.msc (Group Policy Editor)
2. Navigate to: Computer Configuration > Administrative Templates > System > Filesystem
3. Enable "Enable Win32 long paths"

Or via PowerShell (admin):

powershell

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

Alternative: Move repository closer to root:

bash

# Instead of:
# C:\Users\JohnDoe\Documents\Projects\MyCompany\Frontend\ReactApp

# Use:
C:\git\project

6Handle Windows reserved names

Windows cannot create files or directories with these reserved names: CON, PRN, AUX, NUL, COM1-COM9, LPT1-LPT9.

If the repository contains reserved names:

bash

# Clone with sparse checkout to skip problematic paths
git clone --no-checkout https://github.com/user/repo.git
cd repo
git sparse-checkout init
git sparse-checkout set '/*' '!path/to/CON'
git checkout main

Or use WSL (Windows Subsystem for Linux):

bash

# Clone in WSL where reserved names are allowed
wsl
cd /mnt/c/git
git clone https://github.com/user/repo.git

Rename reserved names in the repository (on Linux/macOS):

bash

git mv aux aux_file
git mv con console
git commit -m "fix: rename Windows reserved names"

7Reset and retry with a fresh clone

If other solutions don't work, start fresh:

bash

# Back up any local changes
cp -r myrepo myrepo-backup

# Remove the problematic repository
rm -rf myrepo

# Clone fresh
git clone https://github.com/user/repo.git myrepo

# On Windows with long path support
git clone -c core.longpaths=true https://github.com/user/repo.git myrepo

For interrupted operations, reset Git's state:

bash

# If checkout was interrupted
git reset --hard HEAD

# Clear any lock files
rm -f .git/index.lock
rm -f .git/*.lock

# Clean untracked files that might be causing conflicts
git clean -fd

# Retry
git checkout feature-branch

Advanced notes

### Understanding File System Differences

Git was designed on Linux where the file system is case-sensitive. Windows (NTFS) and macOS (APFS/HFS+) are case-insensitive by default, leading to subtle but frustrating issues.

| File System | Case Sensitive | Max Path | Reserved Names |
|-------------|----------------|----------|----------------|
| Linux (ext4) | Yes | 4096 chars | None (except . and ..) |
| Windows (NTFS) | No | 260 chars* | CON, PRN, AUX, NUL, COM1-9, LPT1-9 |
| macOS (APFS) | No** | 1024 chars | None |

*Can be extended to 32,767 with registry change
**Can be formatted as case-sensitive

### Symlink Handling

Git stores symlinks as special file entries. On Unix, they're created as actual symlinks. On Windows, handling varies:

bash

# Check symlink handling setting
git config core.symlinks

# Windows: Enable Developer Mode or run as Administrator for symlink creation
# Or configure Git to not use symlinks
git config --global core.symlinks false

When core.symlinks is false, Git creates text files containing the symlink target path instead of actual symlinks.

### Sparse Checkout for Problematic Repositories

If a repository has files that cannot exist on your file system:

bash

# Initialize sparse checkout
git sparse-checkout init --cone

# Include everything except problematic paths
git sparse-checkout set src lib tests
# This excludes everything not listed

# Or use patterns to exclude specific files
git sparse-checkout add '/*'
git sparse-checkout set '!path/to/problem-file'

### Git Worktrees as an Alternative

Instead of switching branches (which can trigger this error), use worktrees:

bash

# Create a worktree for another branch
git worktree add ../feature-branch feature-branch

# Work in that directory without conflicts
cd ../feature-branch

# Remove when done
git worktree remove ../feature-branch

### Investigating Lock Issues

On Windows, identify what's locking files:

powershell

# Find process locking a file (requires Handle utility from Sysinternals)
handle.exe path\to\file

# Or use Resource Monitor
resmon.exe
# Go to CPU tab > Associated Handles > Search for file name

On Linux/macOS:

bash

# Find process using a file
lsof path/to/file

# Or
fuser path/to/file

### Cross-Platform Repository Best Practices

To avoid these issues in team repositories:

1. Normalize line endings:

gitattributes

* text=auto
   *.sh text eol=lf
   *.bat text eol=crlf

2. Avoid case-only renames - Change content, not just casing

3. Don't use Windows reserved names - Even if you're on Linux

4. Keep paths short - Especially for node_modules (use --hoist options)

5. Use `.gitattributes` for symlinks:

gitattributes

# Mark symlinks for platforms that don't support them
   path/to/symlink symlink=true

### Checking Repository Health

bash

# Verify repository integrity
git fsck --full

# Check for name conflicts
git ls-files | sort -f | uniq -di

# Check for case conflicts on case-insensitive systems
git ls-files | while read f; do echo "$f"; done | sort -f | uniq -di

How to fix error: cannot create directory 'path': File exists in Git

What this error means

Typical symptoms

Common causes

How to fix "error: cannot create directory 'path': File exists"

Advanced notes

Related errors

Official resources & further reading