Hacker News Reader

Comment by Gladdyu | Hacker News Reader

Though it might finally do away with the ever-persisting Windows error messages about "this file is already open" followed by a search through all of the processes that might have it open to terminate the offender.

View on HN

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.

> 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.

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

Which are thousands...

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.

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

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

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.

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

That foreach looks like it should really be a where

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

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

The way filesystem locking works on Windows is an intentional decision and not an NTFS thing. It's there for a good reason even if it's inconvenient. The alternative has some real downsides. "Two CMD windows have the same CWD but are showing different folders" is not a user-friendly experience.

I bet pretty much every Windows user would trade confusing command prompts in strange circumstances for not having to reboot for pretty much every single Windows Update (due to it being unable to update files that are in use)

It would be horrendous to even try to troubleshoot a system with a dozen different version of OS DLLs loaded because the system had not been rebooted for a dozen patches.

Or, imagine every copy of Word you have running is using a different set of binaries.

No, thank you.

And yet Linux distros some how manage years of uptime with continuous updates.

download sysinternals tools, one of which is "handle" for quickly finding open files.

Yeah, it should come with the OS, but that's Windows for you.

Send To > Unlocker

Hasn't worked since XP, has it? I'd love to see the source for that - I don't know how they were hooking the Copy dialog.

http://www.emptyloop.com/unlocker/

I use it in Win 7; I think it works most of the time (not always).

Reply on news.ycombinator.com