Windows cross-drive temp move can fail with 'file is being used by another process'

[Hellfrosted]

Summary

I am seeing ModpackDebuggerKit fail on Windows during the initial “Preparing... (moving mods to temp directory)” phase when my selected mods folder and os.TempDir() are on different drives. After the failure, the tool leaves a duplicate mod in the temp directory and reports that the mod could not be restored.

Observed log

[21:20:37]  Mod folder: C:\Users\<user>\AppData\Roaming\PrismLauncher\instances\<instance-name>\minecraft\mods
[21:20:37]  Project loaded from <project>.json
[21:20:39]  Starting debug scan with 282 mods...
[21:20:39]  Preparing... (moving mods to temp directory)
[21:20:39]  Failed to move AE2NetworkAnalyzer-1.20-1.0.6-forge.jar: remove C:\Users\<user>\AppData\Roaming\PrismLauncher\instances\<instance-name>\minecraft\mods\AE2NetworkAnalyzer-1.20-1.0.6-forge.jar: The process cannot access the file because it is being used by another process.
[21:20:39]  Failed to restore AE2NetworkAnalyzer-1.20-1.0.6-forge.jar: remove E:\tmp\modpack-debugger-temp-mods\AE2NetworkAnalyzer-1.20-1.0.6-forge.jar: The process cannot access the file because it is being used by another process.
[21:20:39]  Some mods could not be restored. Check E:\tmp\modpack-debugger-temp-mods for remaining files.

Environment

• OS: Windows
• Launcher: PrismLauncher
• ModpackDebuggerKit release: 3.3.0
• Mods folder drive: C:
• Temp folder drive: E: (E:\tmp\modpack-debugger-temp-mods)

Why I think this happens

App.startup sets TempDir from os.TempDir():

a.TempDir = filepath.Join(os.TempDir(), "modpack-debugger-temp-mods")

When the temp folder is on a different drive from my mods folder, moveFile falls back from os.Rename to copyFile. In copyFile, both files are deferred for close, but os.Remove(src) runs before the deferred close of in:

in, err := os.Open(src)
defer in.Close()
// ...
return os.Remove(src)

On Windows this can fail because the file is still open by the same process. That matches what I saw: the copy exists in the destination, but deleting the source fails with “being used by another process”. The same issue can occur during restore from temp back to the mods folder.

Expected behavior

I expected the debugger to successfully move/copy mods even when os.TempDir() is on a different drive, or to choose a temp directory on the same drive as the selected mods folder.

Possible fixes

• Close both source and destination handles before calling os.Remove(src) in the copy fallback path.
• Prefer creating the debugger temp directory next to or inside the selected instance/mods parent so os.Rename can be used on the same volume.
• If using a temp directory on another volume, surface a clearer error and avoid leaving duplicate jars behind.

Workaround

I can work around this by launching the app with TEMP and TMP pointing to a folder on the same drive as the mods folder, for example:

New-Item -ItemType Directory -Force C:\tmp
$env:TEMP = "C:\tmp"
$env:TMP = "C:\tmp"
& "path\to\ModpackDebuggerKit.exe"

[wendellmeset]

Will look into this