Deleting file in use

I wanted to delete a file (or folder that contained this file) that is in use by Windows Media Player.
I got error message saying that it's not possible to delete the file. Depending on whether I wanted to move to thrash or delete it completely, I got different messages. I understand that file in use cannot be (safely) deleted, but DOpus was supposed to show me which application used (had opened) that file so I don't have to use Unlocker, Process Explorer or other utility to see why I can't delete it.

Any ideas why detecting application that uses file I want to delete didn't work this time?

The first message (deleting completely) says that the process can't get access to the file because it's used by another process.
The second says that I'm not permitted to do this action and I have to ask administrators group to apply changes to this folder.

Reporting of which process has the file locked when deleting without the recycle bin is only done for certain file-types (EXE, DLL, maybe a couple of others), since it is done using the Windows API for installers to check which processes have EXEs and DLLs open.

In the recycle bin case, it's up to Windows what's shown in that dialog, but I believe it will list applications which explicitly notify the Windows shell that they have a file open. Office and a few other programs do that but not very many.

So my request is to detect application using the file for all kinds of files.

Actually, I was confused earlier; the check isn't restricted to only EXE and DLL files (I was thinking of something else), and is done for any file on a "real" filesystem when deleting (without the recycle bin) if the error is access denied or a sharing violation.

If nothing is shown in that situation then the Windows restart manager API is unable to detect which process has the file open.

I've questioned this a few times when I've run into it... and I've found a few times where Opus seems unable to identify the locking process, but yet Unlocker is able to figure it out. :frowning: Don't know if that means there's a viable ~known alternative to the method you're using - or if Unlocker is using some hackish way of figuring out the process. Before I found out about Unlocker, I had relied on sysinternals handle.exe... but similarly found that it too often returned no open handles to the file(s) in question. Blah...

I don't know exactly how Unlocker gets the list, but I suspect I know the method, and it's not one that makes sense to use routinely (i.e. every time there's an error dialog while deleting a file), IMO (much like Unlocker's unlocking method itself).