[otterley]

That error is orthogonal to the filesystem in use. Every OS that provides exclusive locking, regardless of filesystem, will return an error if more than one process wants to acquire such a lock.

[tracker1]

    PS> $lockedFile="C:\Windows\System32\wshtcpip.dll"
    PS> Get-Process | foreach{$processVar = $_;$_.Modules | foreach{if($_.FileName -eq $lockedFile){$processVar.Name + " PID:" + $processVar.id}}}

[jodrellblank]

    PS C:\> gps |? {$_.Modules.FileName -match "wshtcpip\.dll"} | select name, id

[felixfbecker]

That foreach looks like it should really be a where

[tracker1]

It was copied from stackoverflow... apologies, I just knew it was possible.

[reitanqild]

> Every OS that provides exclusive locking, regardless of filesystem, will return an error if more than one process wants to acquire such a lock.

Obviously.

The super annoying thing is when the OS doesn't try to tell you which process(es) keeps it open and doesn't even ship with built in tooling to let you find out on your own.

I think that is the point GP tries to make.

[Negitivefrags]

Open up "Resource Monitor" and go to the "Disk" tab. Under "Disk Activity" you can see all open file handles.

[kevin_thibedeau]

Certainly not a sensible solution like having a dialog button that gives you all the relevant information immediately and empowers you to solve the problem without a goose chase.

[coldtea]

Which are thousands...

[psykotic]

You need the Sysinternals utilities to make life tolerable: https://docs.microsoft.com/en-us/sysinternals/downloads/hand... from the command line or Ctrl-F in https://docs.microsoft.com/en-us/sysinternals/downloads/proc... if you prefer a GUI. They do a brute-force search over the open handles in all processes, but it's effective.

[noisem4ker]

I prefer this utility: http://www.emptyloop.com/unlocker/

It lets you see which process locked a file, and optionally remove the lock.