Vagrant destroy doesn't remove old Virtualbox VM directory causing issue when Vagrant up

[breisig]

This has been happening for a long time now randomly but has started to happen alot more frequently. I am using Windows 11 Pro, Latest Vagrant 2.2.9, Latest Virtual [6.1.34] and I have a Vagrant Image [virtualbox-rocky8-202205.box]. When I run 'vagrant up', It installs the image correctly in Virtualbox and I see the VM folder inside the Virtualbox directory.

C:\Users\admin\VirtualBox VMs

Directory of C:\Users\admin\VirtualBox VMs

2022-05-13  10:18 AM    <DIR>          .
2022-05-13  10:18 AM    <DIR>          ..
2022-05-13  10:17 AM    <DIR>          localdevelopment-rocky8-202205

However, When I run 'vagrant destroy'. It destroys the image from Virtualbox correctly and when it's destroyed correctly, the VM folder is deleted in the Virtualbox VM's folder but randomly, the folder is still left in the VirtualBox VM's folder which causes issues when I try to 'vagrant up' again.

If the old VM folder is left in the Virtualbox VM's folder, here's what happens when you 'vagrant up'

C:\b>vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Box 'virtualbox-rocky8-202205.box' could not be found. Attempting to find and install...
    default: Box Provider: virtualbox
    default: Box Version: >= 0
==> default: Box file was not detected as metadata. Adding it directly...
==> default: Adding box 'virtualbox-rocky8-202205.box' (v0) for provider: virtualbox
    default: Unpacking necessary files from: file://C:/b/virtualbox-rocky8-202205.box
    default:
==> default: Successfully added box 'virtualbox-rocky8-202205.box' (v0) for 'virtualbox'!
==> default: Importing base box 'virtualbox-rocky8-202205.box'...
==> default: Matching MAC address for NAT networking...
==> default: Setting the name of the VM: localdevelopment-rocky8-202205
The name of your virtual machine couldn't be set because VirtualBox
is reporting another VM with that name already exists. Most of the
time, this is because of an error with VirtualBox not cleaning up
properly. To fix this, verify that no VMs with that name do exist
(by opening the VirtualBox GUI). If they don't, then look at the
folder in the error message from VirtualBox below and remove it
if there isn't any information you need in there.

VirtualBox error:

VBoxManage.exe: error: Could not rename the directory 'C:\Users\admin\VirtualBox VMs\packer-localdevelopment_1652455116095_25967' to 'C:\Users\admin\VirtualBox VMs\localdevelopment-rocky8-202205' to save the settings file (VERR_ALREADY_EXISTS)
VBoxManage.exe: error: Details: code E_FAIL (0x80004005), component SessionMachine, interface IMachine, callee IUnknown
VBoxManage.exe: error: Context: "SaveSettings()" at line 3265 of file VBoxManageModifyVM.cpp

When I go into the VirtualBox VM's folder, I see the following now

C:\Users\admin\VirtualBox VMs>dir
 Volume in drive C has no label.


 Directory of C:\Users\admin\VirtualBox VMs

2022-05-13  10:18 AM    <DIR>          .
2022-05-13  10:18 AM    <DIR>          ..
2022-05-13  10:17 AM    <DIR>          localdevelopment-rocky8-202205
2022-05-13  10:19 AM    <DIR>          packer-localdevelopment_1652455116095_25967
               0 File(s)              0 bytes

Because the old folder existed, Vagrant cannot successfully bring up a new VM. It's during the destroy, it didn't delete the old folder [again, it's not all the time but is starting to happen more and more frequently].

The only workaround I found was to

1. 'vagrant destroy' that session
2. Go into the Virtualbox VM folder[C:\Users\admin\VirtualBox VMs] and delete the old folders [ localdevelopment-rocky8-202205]
3. Run 'vagrant up' and it works fine then.

This has been happening for a long time now.

Vagrant version

2.2.19

Host operating system

Windows 11 Pro x86 Virtualbox 6.1.34 Virtualbox 6.1.32 Virtualbox 6.1.30

This is the operating system that you run locally.

Guest operating system

Using RockyLinux but it doesn't matter

[xuhcc]

Vagrant 2.3.6, VirtualBox 7.0.10 - same issue.

[countzero]

Still an issue with Vagrant 2.4.3 and VirtualBox 7.1.4.