How to fix error: unable to unlink old 'file.txt': Permission denied in Git

First, find out what program is preventing Git from accessing the file. There are several ways to do this on Windows:

Using Process Explorer (recommended):
1. Download Process Explorer from Microsoft Sysinternals: https://docs.microsoft.com/sysinternals/downloads/process-explorer
2. Run Process Explorer as Administrator
3. Press Ctrl+F to open "Find Handle or DLL"
4. Enter the filename (e.g., "file.txt")
5. Click "Search" - it will show which process has the file open

Using Handle utility (command-line):

# Download Handle from Sysinternals and run:
handle.exe file.txt

Using PowerShell (Windows 10/11):

# Find processes with matching file handles
Get-Process | ForEach-Object {
    $process = $_
    try {
        $_.Modules | Where-Object { $_.FileName -like "*file.txt*" } |
        ForEach-Object { Write-Host "$($process.Name) [$($process.Id)]" }
    } catch {}
}

Using Resource Monitor:
1. Press Win+R, type resmon, press Enter
2. Go to the "CPU" tab
3. Expand "Associated Handles" section
4. In the search box, type the filename
5. See which processes have handles to that file

Once you've identified the culprit, close that application or release the file lock:

Common culprits and solutions:

IDE/Editor (VS Code, IntelliJ, etc.):
- Close the specific file in the editor
- Or close the entire project/folder
- Some IDEs have a "Reload from Disk" feature that releases handles

Windows Explorer Preview Pane:
- Click on a different file
- Or disable the preview pane: Alt+P in Explorer
- The preview pane commonly locks PDF, image, and document files

Antivirus Software:
- Add your repository folder to the antivirus exclusions list
- This is especially important for Windows Defender real-time protection

Build/Test processes:
- Stop any running builds or test suites
- Check for background watchers (npm run watch, webpack --watch, etc.)
- Kill orphaned node.exe, java.exe, or python.exe processes

After closing the application, retry your Git command.

Git Bash handles file operations differently than Windows Command Prompt and can sometimes work around locking issues:

# In Git Bash, navigate to your repo
cd /c/path/to/your/repo

# Retry the operation
git checkout branch-name
# or
git pull origin main

Git Bash uses MSYS2's file handling which can be more forgiving with file locks in some situations.

Why this can help:
- Git Bash may handle file path translations differently
- Some Windows-specific locking behavior is avoided
- The shell environment is more Unix-like in its file handling

If you can't close the application holding the file, you can forcibly release the handle:

Using Handle from Sysinternals:

# First, find the handle (run as Administrator)
handle.exe file.txt

# Output shows something like:
# explorer.exe   pid: 1234  type: File  ABC: C:\path\to\file.txt

# Close the handle (use the hex handle value shown)
handle.exe -c ABC -p 1234

Warning: Force-closing handles can cause data loss or application crashes in the program that had the file open. Save your work in that application first if possible.

Using Process Explorer:
1. Find the process in the list
2. Click on it, then press Ctrl+H to show handles
3. Find the file handle in the lower pane
4. Right-click and select "Close Handle"

If nothing else works, a reboot will release all file locks:

# Save your work, then reboot
shutdown /r /t 0

After rebooting:
1. Open Git Bash or Command Prompt immediately (before any IDE)
2. Navigate to your repository
3. Run the Git command that was failing
4. Only then open your IDE or other applications

This works because the reboot clears all file handles. The key is to run Git before anything else opens the files again.

For persistent issues:
If the same files are always locked after reboot, check your startup programs:
- Press Win+R, type shell:startup
- Remove or disable startup items that might open those files
- Check Windows Services for background processes

Some Windows features aggressively lock files. Consider disabling them for your development folders:

Disable Windows Search Indexer for your repo:
1. Right-click the repository folder
2. Click "Properties"
3. Click "Advanced..."
4. Uncheck "Allow files in this folder to have contents indexed"
5. Apply to all subfolders

Disable Windows Defender real-time scanning (temporarily):

# In elevated PowerShell
Set-MpPreference -DisableRealtimeMonitoring $true

# Remember to re-enable after your Git operation
Set-MpPreference -DisableRealtimeMonitoring $false

Or add exclusions (preferred):
1. Open Windows Security
2. Go to Virus & threat protection > Manage settings
3. Under Exclusions, click "Add or remove exclusions"
4. Add your repository folders and .git directories

Disable Superfetch/SysMain (extreme):

net stop SysMain

This is rarely necessary but can help if Windows prefetch is causing issues.

Sometimes the error really is about file permissions, not locks:

Check file ownership:

# View current permissions
icacls "path\to\file.txt"

# Take ownership
takeown /f "path\to\file.txt"

# Grant full control to your user
icacls "path\to\file.txt" /grant "%USERNAME%":F

For the entire repository:

# Take ownership of entire repo (run as Administrator)
takeown /f "C:\path\to\repo" /r

# Reset permissions
icacls "C:\path\to\repo" /reset /t

Common permission scenarios:
- Cloning a repo as Administrator but running Git as regular user
- Copying a repo from another machine or external drive
- Repository on a network drive with different permissions
- Files extracted from a zip/archive with restrictive permissions

On Windows, very long file paths can cause permission-like errors. Enable long path support:

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

Enable in Windows (Windows 10 1607+):
1. Press Win+R, type gpedit.msc
2. Navigate to: Computer Configuration > Administrative Templates > System > Filesystem
3. Enable "Enable Win32 long paths"

Or via Registry:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem]
"LongPathsEnabled"=dword:00000001

This is especially relevant for node_modules, deeply nested project structures, or projects cloned from Unix systems with long paths.