Unable to delete
Moderator: Barb@Invincea
Unable to delete
Hi! I use a registered Sandboxie x64 in Windows 7 Ultimate x64 and found out something just now. Maybe it's a known thing, but I'll ask anyway. So:
If I sandbox Windows Explorer and create an txt file on my D drive (this is just an example) and the also open a non-sandboxed Windows Explorer and go into
C:\Sandbox\UserName\, then when I terminate the sandbox the automatic delete doesn't work. Also if I try to do it manually, it doesn't work - it says access denied.
So, is this behavior normal? I was expecting that the delete would succeed and that in the unsandboxed W. Explorer I would see the contents of the sandbox disapper. So?
Thank you!
If I sandbox Windows Explorer and create an txt file on my D drive (this is just an example) and the also open a non-sandboxed Windows Explorer and go into
C:\Sandbox\UserName\, then when I terminate the sandbox the automatic delete doesn't work. Also if I try to do it manually, it doesn't work - it says access denied.
So, is this behavior normal? I was expecting that the delete would succeed and that in the unsandboxed W. Explorer I would see the contents of the sandbox disapper. So?
Thank you!
-
- Posts: 2690
- Joined: Tue Dec 26, 2006 5:44 pm
- Location: West Florida
Possibly the non-sandboxed explorer or some program on your computer is keeping a "lock" on the folder or something, preventing Sandboxie from auto-deleting the sandbox, or maybe it's intentional behavior in Sandboxie?
I just tried it myself though but was unable to reproduce the issue? Which version of Sandboxie are you using?
I just tried it myself though but was unable to reproduce the issue? Which version of Sandboxie are you using?
In my experience, if you view a sandbox using an unsandboxed Windows Explorer, it will often retain handles on the sandbox and prevent Sandboxie from deleting it. (This assumes that at some point you went deeper than just C:\Sandbox\UserName\.) The solution for me is just to close the unsandboxed Explorer, or delete the sandbox manually using the unsandboxed Explorer.
-
- Posts: 2690
- Joined: Tue Dec 26, 2006 5:44 pm
- Location: West Florida
Hmm, well previously I only went to "C:\Sandbox\UserName\" as the OP stated and it auto-deleted just fine, but even if I go deeper (C:\Sandbox\UserName\DefaultBox) it still deletes fine.
Sure it doesn't delete right away, first it is renamed to "Delete_..." and just stays there, but if I browse back one directory (to C:\Sandbox\UserName\) or close the Explorer window, then the "Delete_..." folder deletes automatically afterwards.
Sure it doesn't delete right away, first it is renamed to "Delete_..." and just stays there, but if I browse back one directory (to C:\Sandbox\UserName\) or close the Explorer window, then the "Delete_..." folder deletes automatically afterwards.
Ha, that's what I get for working from memory. Looks like we have to go another subfolder deeper.SnDPhoenix wrote:... but even if I go deeper (C:\Sandbox\UserName\DefaultBox) it still deletes fine.
Steps:
- 1. In an empty DefaultBox, run Windows Explorer to populate the sandbox.
2. Right-click > Terminate Programs.
3. (Optional) Use Process Explorer to confirm that there are no open handles to DefaultBox (ignore the system process).
4. Run an unsandboxed Windows Explorer by pressing WindowsKey+E.
5. In Explorer's right-hand pane, step down in direct succession to the folder mentioned below.
6. Right-click > Delete Contents.
7. (Reset the test by closing all Explorer windows and deleting the sandbox.)
- - C:\Sandbox\UserName\DefaultBox\: I get the same behavior as you. However, if in Step 4 I instead use right-click > Explore Contents, then Start.exe says: "... Access is denied. (5)"
- C:\Sandbox\UserName\DefaultBox\user: When going one level deeper, the sandbox consistently fails to delete and I get: "... Access is denied. (5)"
Tested with Sandboxie 3.55.01 on Windows 7 SP1 x64.
-
- Posts: 2690
- Joined: Tue Dec 26, 2006 5:44 pm
- Location: West Florida
Sorry SnD, I latched onto the part where OP said "manually" because that's what I had experience with.Bellzemos wrote:... then when I terminate the sandbox the automatic delete doesn't work. Also if I try to do it manually, it doesn't work - it says access denied.
Ok, I retried the steps with auto-delete on and got the same results. It didn't seem to make a difference if in Step 2 I closed Explorer using only Ctrl+w, except that explorer.exe lingers for a bit after its window disappears.SnDPhoenix wrote:Instead it looks like you're manually terminating the sandbox and manually deleting instead.
From what I've seen, Sandboxie is behaving properly. It's just annoying that the unsandboxed Explorer doesn't close those handles after you go back up the folder tree.
-
- Posts: 2690
- Joined: Tue Dec 26, 2006 5:44 pm
- Location: West Florida
Ok well I had a chance to reproduce your steps.
When browsing to C:\Sandbox\UserName\DefaultBox\ instead, I get the same results as earlier, sandbox renames to "Delete..." but it doesn't actually delete until I go back one directory (to C:\Sandbox\UserName\) or close the Explorer instance.
When browsing to C:\Sandbox\UserName\ the sandbox deletes fine.
I've tried reproducing these steps with auto-delete turned on and off, and by trying both terminating sandboxed programs and just simply closing sandboxed programs, and my results are exactly as listed above every time.
This is exactly the same results I got, but only if I manually delete! If I have auto-delete enabled, then when all processes are terminated, you can see your mouse turn to a hourglass (as if Sandboxie is doing something) and then it goes away and you never receive any error messages from Sandboxie about "Access denied" or anything like that, though the sandbox doesn't delete...- C:\Sandbox\UserName\DefaultBox\user: When going one level deeper, the sandbox consistently fails to delete and I get: "... Access is denied. (5)"
When browsing to C:\Sandbox\UserName\DefaultBox\ instead, I get the same results as earlier, sandbox renames to "Delete..." but it doesn't actually delete until I go back one directory (to C:\Sandbox\UserName\) or close the Explorer instance.
When browsing to C:\Sandbox\UserName\ the sandbox deletes fine.
I've tried reproducing these steps with auto-delete turned on and off, and by trying both terminating sandboxed programs and just simply closing sandboxed programs, and my results are exactly as listed above every time.
We're seeing the exact same thing. When I said "same results" I was referring to everything except that message. My fault.SnDPhoenix wrote:If I have auto-delete enabled ... you never receive any error messages from Sandboxie about "Access denied" or anything like that ...
All that testing and... have we actually accomplished anything? Ha.
-
- Posts: 2690
- Joined: Tue Dec 26, 2006 5:44 pm
- Location: West Florida
So this is common (normal) behavior, Sandboxie is still steel solid and everything is OK? To avoid this I shouldn't be in the Sandbox folder when terminating a sandbox, right? Or is there anything else?
Oh, and about the "locked" thing - I'm a new user of Windows 7 (I've been using XP for a long time) and don't know how to remove all the locks from the folders in Windows Explorer. I can't even access all the folders, how can I disable those locks? And maybe that will help Sandboxie delete the sandbox at any time too.
Oh, and about the "locked" thing - I'm a new user of Windows 7 (I've been using XP for a long time) and don't know how to remove all the locks from the folders in Windows Explorer. I can't even access all the folders, how can I disable those locks? And maybe that will help Sandboxie delete the sandbox at any time too.
As far as I can tell, everything is ok. When Windows Explorer has handles open on the sandbox, this prevents Sandboxie (and presumably other programs) from deleting it. So just close the unsandboxed Explorer.Bellzemos wrote:So this is common (normal) behavior, Sandboxie is still steel solid and everything is OK? To avoid this I shouldn't be in the Sandbox folder when terminating a sandbox, right? Or is there anything else?
"Locked" can mean different things. In the above posts, we were referring to a temporary "lock" on the sandbox, because it was still in use. When you say you can't access a folder at all, that's something else - I would guess that you're referring to either:Bellzemos wrote:Oh, and about the "locked" thing - I'm a new user of Windows 7 (I've been using XP for a long time) and don't know how to remove all the locks from the folders in Windows Explorer. I can't even access all the folders, how can I disable those locks?
- 1) Folders like C:\Documents and Settings or %UserProfile%\Application Data, which result in an "Access is denied" message - These are actually junctions, which point from the old XP path to the new Windows Vista/7 path. If you want to access the location, you'll have to go directly to the target path, e.g. C:\Users or %UserProfile%\AppData\Roaming.
2) Folders blocked by your NTFS permissions, which are set to deny certain access privileges to your user account. See here for more info.
Thank you for your detailed post Mike. I think it's the second thing. In XP I was able to see into all the folders on my HDD (except for the System Volume Information folder). Now many of the folders have locks on them and some I can access and some I can't. Is there a simple way which would grant me access to all the folders on my HDD (as it was on XP) without compromising security on my laptop?
Hmm, permissions can get messy and I don't really feel comfortable giving advice. But, assuming that your problems stem from your upgrade to Windows 7, then the Microsoft article I mentioned above does have a section called "I installed a new version of Windows and now I can't open a folder." Does it help? If you're the only user on the computer, it might make sense to simply apply the steps from that article to the root of any non-system partitions, e.g. D:\.Bellzemos wrote:Is there a simple way which would grant me access to all the folders on my HDD (as it was on XP) without compromising security on my laptop?
Btw, people often talk about using icacls or secedit - but icacls might not be that easy, and secedit technically isn't supported on Windows 7.
Who is online
Users browsing this forum: No registered users and 1 guest