Problem
runtime_install_root_is_protected (crates/rocm-core/src/runtime.rs) decides whether a runtime folder sits somewhere too dangerous to delete by enumerating known-bad locations. That means anything it has not thought of is treated as safe. It returns false for $HOME exactly, and for /home, /mnt, /srv and /media; the Windows branch hardcodes C:, so another drive letter is unprotected.
Nothing reaches those gaps today: deletion additionally requires a matching in-tree .rocm-cli-runtime.json whose runtime_key, runtime_id and install_root all agree, which a copied or moved tree does not satisfy. So this is a defence-in-depth guard rather than a live bug.
Why it matters now
rocm storage remove-old-installs (#172) leans on this guard for a set of folders the user never typed out, which is a different risk profile from rocm runtimes uninstall naming one. Belt-and-braces guards are worth having actually hold.
Suggested direction
Invert it: require the folder to be under a known ROCm CLI data root (or otherwise positively established as ours) rather than merely not matching a list of bad places. Platform-independent handling for Windows drive roots too.
Context
Out of scope for #172. Raised from review feedback on that PR.
Problem
runtime_install_root_is_protected(crates/rocm-core/src/runtime.rs) decides whether a runtime folder sits somewhere too dangerous to delete by enumerating known-bad locations. That means anything it has not thought of is treated as safe. It returns false for$HOMEexactly, and for/home,/mnt,/srvand/media; the Windows branch hardcodesC:, so another drive letter is unprotected.Nothing reaches those gaps today: deletion additionally requires a matching in-tree
.rocm-cli-runtime.jsonwhoseruntime_key,runtime_idandinstall_rootall agree, which a copied or moved tree does not satisfy. So this is a defence-in-depth guard rather than a live bug.Why it matters now
rocm storage remove-old-installs(#172) leans on this guard for a set of folders the user never typed out, which is a different risk profile fromrocm runtimes uninstallnaming one. Belt-and-braces guards are worth having actually hold.Suggested direction
Invert it: require the folder to be under a known ROCm CLI data root (or otherwise positively established as ours) rather than merely not matching a list of bad places. Platform-independent handling for Windows drive roots too.
Context
Out of scope for #172. Raised from review feedback on that PR.