v2.7x Files with "Acces Denied" in the Sandbox

[eternalbeta]

By now I've accumulated several files, which were downloaded and unrarred etc, in different sandboxes which can't be deleted and thus, neither the sandbox itself. The moment you try open, move or delete such a file you get the message "Access Denied".

Some I could get rid of with the help of a program called Dr. Delete but the others won't budge. I also tried to disable sandboxie to run at startup and then booting in safemode but even then you get "Access Denied"

Any suggestions how to get rid of these files and how to avoid this error?

[tzuk]

Try Properties on the file, Security tab, the Advanced button near the bottom, then the Owner tab, and change the ownership of the file to you.
Click OK, then go to the Security tab again, and give yourself Full Access to the file. Click OK again. Now you should be able to access them. Hopefully.

[eternalbeta]

Tzuk, I followed your advise and looked at the properties and it turns out that the correct description should be "non accessable" folders, not files.

Thus, the properties show only 3 tabs (general, sharing and customize). General showed that it concerns File folders of 0 bytes size, containing 0 files and 0 folders, with a read-only attribute.

I didn't manage to change anything in attributes or whatever, so they're still there. I've never seen this kind of problematic folders before and I only have them in the sandboxes.

Any other suggestions as to how to get rid of them as, because of this problem, I also can't delete the sandboxes in question.

[mart]

I had alot of trouble with this when using version 2.64. The reason I had lots of sandbox folders in 'Application Data' was because a backup seemed to be created every time I did an XP System Restore.

I eventually noticed this but was unable to delete the folders (Access denied). I tried lots of things including working with XP's Recovery Console (the default capabilities of this can be extended). This gave some success deleting files within the folders. But there was one stubborn file buried deep within each one that refused to go (flash9.ocx). The cure was simple in the end. Just a little different to the advice already given.

Rename the flash9.ocx to flash9.ocx.txt, Click 'Ignore' when the error message arises.
Right-click the file and go to 'Properties > Security > Advanced'.
Select and remove any permission that says 'Deny'.
Close properties.
Delete flash9.ocx.txt (thanks to post #16 here).

Maybe you could see if you have a similar situation with a file within the folders?

These days, whenever I do a System Restore, I always make sure the sandbox is emptied first. This seems to avoid the problem.

[eternalbeta]

Thanks Mart for your suggestions. However, renaming turns out to be impossible due to the "access denied" problem.

I've tried killbox but no luck there. Then I downloaded and installed GiPo@Utilities with a trial key from http://www.gibinsoft.net/gipoutils/index.htm.

Although this program also didn't succeed in deleting the folders at least things became a bit clearer because when I added the three folders for deletion at reboot, the program warned that the folders were not empty at all. In the end one folder only could be added for deletion while the other two were blocked immediately with "access denied".

After reboot this one folder was still there however, it now showed a file size of 1.7 Mb instead of 0 bytes and contained 3 files and 0 folders plus still read-only as attribute but I could now open the folder and see the 3 files inside but all are "access denied". Inside are an exe, a txt and a html file with different numbers of tabs in properties but no security tab where I could change the ownership.

So there is a problem with wrong sizes and content involved with this "access denied" problem but in the end the folders are still there and no security tab is shown where to change ownership. The presence of these folders, which also prohibit the elimination of the sandboxes, kinda defeats also one of the purposes of the sandboxing itself I'm afraid.

Any other suggestions please?

[mart]

To be able to set permissions on any individual file or folder you first need to disable 'file sharing'. If this is done, the file permission options should become available for you to change. To disable file sharing:

* Click 'Start'.
* Click 'My Computer'.
* Click on the 'Tools' menu.
* Click 'Folder Options'.
* Click the 'View' tab.
* In the Advanced Settings section, clear the 'Use simple file sharing (Recommended)' check box.
* Click OK.

http://support.microsoft.com/kb/307874

[Cadillakin]

Deltree would delete those file/folders for sure. Without deltree (win98) in your arsenal, try to remove the folder by issuing the rd (winxp "remove directory) command. Open a command prompt, go to the file/folders parent, and type:

rd /s <folder name>

Thus, if one wanted to delete the folder Sandbox, which was a subfolder of the root C, we would change into C:, and type this command

rd /s sandbox

It's more effective issued from winxp's recovery consul but it will generally work from a plain command prompt within windows. Good luck.

[eternalbeta]

Bingo, thanks Mart. Your latest suggestion together with Tzuk's first reply did it

To be able to set permissions on any individual file or folder you first need to disable 'file sharing'. If this is done, the file permission options should become available for you to change. To disable file sharing:

* Click 'Start'.
* Click 'My Computer'.
* Click on the 'Tools' menu.
* Click 'Folder Options'.
* Click the 'View' tab.
* In the Advanced Settings section, clear the 'Use simple file sharing (Recommended)' check box.
* Click OK.

Try Properties on the file, Security tab, the Advanced button near the bottom, then the Owner tab, and change the ownership of the file to you.
Click OK, then go to the Security tab again, and give yourself Full Access to the file. Click OK again. Now you should be able to access them.

Once I got a security tab I was able to follow Tzuk's directions and now al three folders are finally gone and I could also delete these sandboxes now. Thanks also to Cadillakin for his suggestion.