File in use - who has my file locked?

[Sommerbo]

CRUTKAS: changing this based on a comment by @oldnewthing.

Tell me WHO has the file locked, not just drop the handle. Dropping the handle can have bad side effects

---

ORIGINAL POST

When deleting files, sometimes files are locked for no apparent (to the user) reason coughthumbs.dbcough. The program "Unlocker" could be used, but it really should be a power toy with smarter integration to the OS, deleting thumbs.db is harmless, deleting ntoskrnl.exe could be bad. So a toy for smartly dropping open file handles could be useful.

[ysc3839]

I think a program to see what program is using that file is a good solution. Force closing/deleting may cause undefined behavior.

[Sommerbo]

True, but force closing user started processes COULD work.

[amithegde]

I have been looking for this for so many years. Raised a request to OS folks and they just closed it saying it's too hard for them. A power toy for this saves us from restarting computer to unlock a file from whoever has a lock on it!

[crutkas]

http://www.emptyloop.com/unlocker/ for unlocker, Process explorer can do this as well. https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer

[NickCraver]

In looking at this, it sees to be that this is one of those things that really should be in the base OS. I'd say 60% of the time that I hit a need for this, it's with an installer. That front would be best improved with an API, and the installer world isn't likely to take a dependency on PT. Also think of just deleting a file from Explorer in general - you'd want to see it right there.

While I'd love for PT to implement this for the cases it does cover...I do feel it's really the wrong place for a solution in this case. I'm not sure how we lobby the Windows team to add it in though...

[Jay-o-Way]

Raised a request to OS folks and they just closed it saying it's too hard for them

OMG really? Too difficult for developers? "nil volentibus arduum"

[amithegde]

Raised a request to OS folks and they just closed it saying it's too hard for them

OMG really? Too difficult for developers? "nil volentibus arduum"

Well, not as easy as messing with start menu background color😂

I just use Sysinternals Process Explorer to figure out who holds the lock these days.

[oldnewthing]

Force-closing handles creates data corruption, because the handle you forced closed will get reused for something else, and then the original code will now be writing to the wrong file.

Detailed discussion here.

[enricogior]

@crutkas based on Raymond comment, this is not something we want to add to PT.

[lukebarone]

What about showing the process that has the open file?

[crutkas]

@lukebarone, I think that is a better approach and ironically what i named this issue in the roadmap doc.

[oldnewthing]

Explorer already does this when it can find out.

[crutkas]

@oldnewthings, from my experience, I always get vagueness, never something targeted. A great example is at times trying to delete my bin folder and explorer is like ¯_(ツ)_/¯ do you want to skip

[Jay-o-Way]

Would this also be possible for USB hard drives and USB thumb/flash drives? Sometimes, when I want to disconnect an external drive, it tells me it's in use.

[zspitz]

Not sure of the right terminology, but if it's a process with a visible window, perhaps PT should offer to bring it to the foreground.

[touriga57]

Would this also be possible for USB hard drives and USB thumb/flash drives? Sometimes, when I want to disconnect an external drive, it tells me it's in use.

For me this is one of the 2 most common use cases and need for this rather than going through the pain and in-efficiency of using Process Explorer.

[touriga57]

For me the real value of this PT proposal is to quickly identify unexpected (often background) processes locking a file. Common culprits I have found are:

• the USB drives being locked as mentioned by @Jay-o-Way
• applications with preview panes open and coincidently parked on the same file
• background synchronisation or cloud backup applications currently processing the file
• Services
• TSRs (is that still a term/concept?) that are locking files (e.g. Outlook, Chrome).

[TheAndyMac]

I definitely agree that this would be a really useful addition to PowerToys - and definitely if it could have more "intelligence" than other tools in terms of what are safe processes to close and what are not (and showing what processes are locking the file) would be a big benefit.

Personally I use IObit Unlocker and have found this to be pretty reliable, especially for situations when programs have crashed and left threads open blocking files (and sometime stopping you restarting the program), or those programs that just don't release them properly when you would expect them to --- for example Outlook when you close a PST file that you had opened (e.g. an archive file that you wanted to find something in) :-(

[martixy]

This is a common gripe with just about every windows user, and would certainly be a terrific idea for a power toy.

Someone above mentioned Explorer already does this, but failed to note it does so in a highly unreliable fashion - sometimes you do indeed get a hint. Most times, you do not.

Many power users have already found solutions to this issue on their own, and while stand-alone programs make it easy to blindly get the job done, Process Explorer can find each process that has a stubborn handle and can often inform how safe it is to close them individually. For example sometimes a browser might lock a file, and I can just restart the browser or close the tab hosted by that process, instead of forcing the handle. Incredibly versatile tool, should be part of any power user's kit.

[oldnewthing]

The proposed PowerToy would just use RmRegisterResources, which is the same API that Explorer uses, so it would fail in the same way. If you have a reproducible scenario where RmRegisterResources fails to identify the process that is holding a file handle open, please let me know so I can report it to the RmRegisterResources owners.

[antiufo]

@oldnewthing If I understand correctly, applications would be expected to call RmRegisterResources when they open a file (eg. NtCreateFile) just so that the user gets a descriptive error message if they try to delete that file while it's still in use by that process?

Repro steps:

1. Create an empty folder
2. Open cmd and cd into that folder (don't use PowerShell since it doesn't actually change the working directory when you cd)
3. Try to delete that folder using Explorer.

Expected outcome: "This folder is in use by cmd.exe [PID]" Actual outcome: "Folder In Use - The action can't be completed because the folder or a file in it is open in another program".

It doesn't tell you that cmd.exe is responsible for this. Whereas if you use for example Process Hacker, it successfully finds that it's in use by cmd.exe

[antiufo]

On the other hand, if you open PowerShell and type $a = [IO.File]::Create("$env:UserProfile\Desktop\test.dat"), and then try to delete that file using Explorer without first closing the PowerShell window, it correctly tells you that the file is still in use by pwsh.

So it gives you a descriptive error message if the resource in use is a file handle, but not if it's a working directory.

[oldnewthing]

Okay, the "current directory" one I can believe, but the fact that people complain about this so rampantly tells me that there's some other file-based scenario that's slipping through the cracks. RmRegisterResources is supposed to work for files without any cooperation from the file handle opener.