Clicking "Cancel" in the overwrite confirmation dialog for file recovery results in a sandbox that cannot be deleted. In the procedure below, Step 4 is the key.

Steps to reproduce:

1. Create an empty text file on your sandboxed desktop.
2. Create another text file of the same name on your real desktop.
3. Run Sandboxie's "Delete Contents" command. Then, click "Recover to Same Folder".
4. When the "Move File" prompt asks whether to "Move and Replace", "Don't move", etc., click the "Cancel" button. (On XP, click "No".)
5. Now, click "Delete Sandbox". Deletion should fail with this start.exe message: "Could not move the sandbox folder out of the way ... Access is denied."

At this point, Process Explorer shows a single SbieCtrl.exe handle on the sandboxed Desktop folder; trying to force the handle closed results in an error. Repeated attempts to delete the folder in Sandboxie Control and/or Windows Explorer fail.

The usual suggestion around here seems to be Unlocker. But in this case, if Sandboxie Control is part of the issue, then perhaps something can be fixed.

Workaround: Don't click the "Cancel" button. Or restart Sandboxie Control if you accidentally do.

Tested on Windows 7 x86 and x64, with Sandboxie 3.49.11 and a default sandbox. Also tested on XP with 3.46. This behavior has been around since at least 3.44.

By the way, Guest10, I see you have a similar open issue from 2009: http://www.sandboxie.com/phpbb/viewtopic.php?t=4837
I was going to reply there, but this seems to be slightly different since you just chose to Delete Contents, whereas here the issue occurs only after cancelling recovery.

Hmm, maybe this bug is specific to v3.49.11?
I didn't upgrade yet, but I just tried this in v3.49.10 on Win7 x86 and the sandbox deleted fine...

I'll upgrade to the latest beta now and try it again.

Edit:
Yeah, I just upgraded and it still deletes the sandbox without any problems.
Can someone else test this, I wanna see if its just me or if it is just Mike.

I used Unlocker to identify what is locked, and by who. Otherwise, my test was the same:
So, the lock is on the sandboxed "Desktop" folder.

Further, after deleting the test file on my real Desktop, and then recovering the test file to the Desktop:
I still cannot 'delete contents' of the sandbox.
I have 2 instances of Control locking the"Desktop" folder in the sandbox.
Edit: During additional testing I haven't been able to show 2 locks on the folder, like I did the first time.

I've reproduced this consistently on 3 machines over the past 6 months, so I'm pretty sure it's not just 3.49.11.


But it could be just me! And Guest10.

Thanks for checking this, guys.

Hmm, could it possibly be another security program on your system causing Sandboxie to put a lock on the folder... somehow?
I see from Guest10's signature that he's using other programs, but I don't know about you Mike.

It might help if others test this too.

Thanks Mike, I'll check it out. Would be nice if I could fix that problem from 2009..

I run KIS 2010 or 2011, and nothing else. But I reproduced this with SB 3.46 in an XP virtual machine that's pretty close to stock, with no security software at all. I think Sandboxie is playing favorites, and behaves extra nice for you.

@tzuk: Thanks!

Maybe the problem lies in how you reproduce this issue?
I'll post my steps, just in case it differs from you guy's steps.

I created a new sandbox, then I ran notepad in that sandbox. I typed "Test" and saved the file to my desktop as "Test". Immediate Recovery prompted me to recover the file, but I just ignored it and closed the window.
Then outside my sandbox I ran notepad, typed "Test" and saved it as "Test" again.
I right clicked the sandbox, deleted the contents, and in the quick recovery box was the Test.txt file.
I selected it, clicked "Recover to same folder" and when the overwrite prompt popped up, I just clicked cancel.
I then clicked the "Delete Sandbox" button and it deleted the sandbox without any problems....

Aha! I tried your steps and the sandbox deletes perfectly time after time.

The small but crucial difference is that you're selecting just "test.txt" for recovery, whereas I always leave the selection on the Desktop folder. Now can you reproduce?

Ahh that was it!
Now after leaving the "Desktop" folder selected and trying to "recover to same folder", it spits up the error message!
We found the culprit!

Same results here. If the actual file is selected for recovery then there's no problem.
Like Mike, I typically leave the folder selected during Quick Recovery.

When the folder is selected during Quick Recovery, in this test:
The lock on the folder is applied as soon as you click on the "Recover to Same Folder" button.
If you choose to overwrite the unsandboxed file, the lock on the folder is removed.
If you choose not to overwrite the unsandboxed file, the lock on the folder is not removed.

Good work, guys. I'd reproduced this in so many different ways, but never tried specifically selecting a single file to recover.

This should be fixed in version 3.49.12.

Guest10, I think this will also fix that old problem report from the Open Issues forum, so I've moved that one over to the Beta Version 3.49 Forum as well.

Well, I can't attest to the thread Guest10 created, but I just tried reproducing my steps above, and now the sandbox deletes perfectly!
Nice work!