Some installers refuse to pick a different folder. Move the installed folder with robocopy, leave a directory junction behind and the program keeps working from the new drive without a reinstall.
Close the app, move its folder with **robocopy /MOVE**, then create a link with **mklink /J** at the old path. Windows follows the junction, so shortcuts, registry paths and updates still resolve.
A running process keeps a handle open and robocopy will skip files. **Get-Process** filtered on the executable name finds the obvious culprits before you start moving gigabytes.
Get-Process | Where-Object Path -like 'C:\Program Files\HeavyApp*' | Select-Object Name,Id,Path
Stop-Process -Name HeavyApp -Force -ErrorAction SilentlyContinueSize and file count decide the time and whether the target has room. A junction does not copy anything, so the free space check is about the destination only.
$src = 'C:\Program Files\HeavyApp'
'{0:N1} GB in {1} files' -f ((Get-ChildItem $src -Recurse -File | Measure-Object Length -Sum).Sum / 1GB), (Get-ChildItem $src -Recurse -File).Count
Get-Volume -DriveLetter D | Select-Object DriveLetter,SizeRemaining**robocopy /MOVE** copies the tree, verifies it and deletes the source only when the copy succeeded. That behaviour is why it is safer than cut and paste for a program folder.
robocopy "C:\Program Files\HeavyApp" "D:\Apps\HeavyApp" /MOVE /E /COPYALL /R:2 /W:2 /NP
Test-Path 'D:\Apps\HeavyApp\HeavyApp.exe'
Test-Path 'C:\Program Files\HeavyApp'**mklink /J** needs the original path to be gone and the target to exist. The result is a real directory entry that the file system resolves transparently.
cmd /c mklink /J "C:\Program Files\HeavyApp" "D:\Apps\HeavyApp"
dir /AL "C:\Program Files"
Get-Item 'C:\Program Files\HeavyApp' | Select-Object Name,LinkType,TargetStart the app, let it update, then confirm the new files landed on D. A junction that resolves correctly still writes through to the real folder, which is exactly the point.
Start-Process 'C:\Program Files\HeavyApp\HeavyApp.exe'
Get-ChildItem 'D:\Apps\HeavyApp' | Sort-Object LastWriteTime -Descending | Select-Object -First 5 Name,LastWriteTime**rmdir** deletes the link only. **del** or Explorer delete on a junction can empty the target folder on older builds, so use the command line.
cmd /c rmdir "C:\Program Files\HeavyApp"
Test-Path 'D:\Apps\HeavyApp\HeavyApp.exe'
Test-Path 'C:\Program Files\HeavyApp'robocopy /MOVE left an empty folder behind. Remove it with rmdir, then run mklink again.
Something hard-coded the new path. Point the app back at the original path; the junction makes the location irrelevant only if the app uses the old string.
An installer that deletes and recreates the folder removes the junction. Recreate it with mklink after the update, or install the app to the target drive directly next time.
Some scanners follow reparse points and scan the target twice. Exclude the target folder, not the link, if scan time becomes a problem.
No. A junction exists only for directories and resolves on the local volume; a symbolic link can point to files, UNC paths and even non-existent targets, and it needs admin rights or developer mode to create.
Yes. The registry entry still names the old path, which now resolves through the junction, so uninstall works normally.
Changing a letter moves every program on that volume and breaks shortcuts and services. A junction touches one folder and nothing else.
Close the program, remove the junction with cmd /c rmdir, then move the folder back with robocopy /MOVE from the new drive to the original path. Start the app once to confirm it runs from its original location.
Free · no account needed · tracks your progress