Releasing Windows file share locks

问题:

This problem crops up every now and then at work. Our build machine can have it's files accessed via a normal windows file share. If someone browses a folder remotely on the machine, and leaves the window open overnight, then the build fails (as it has done now). The explorer window left opened points at one of the sub folders in the source tree. The build deletes the source, and does a clean checkout before building. The delete is failing.

Right now, I'd like to get the build to work. I'm logged in from home, and I'd rather not reboot the build machine. I'm unable to get hold of the person whose machine is looking and the files, and I can't remotely reboot their machine.

When a windows share has a lock, the locking process is System, so I don't think I can kill it, as with normal locks.

Does anyone know a way to release the lock on a shared folder without having to reboot the machine?

回答1:

Found a solution.

1. Find the process using Process Explorer:

   1. Download and extract procexp.exe
   2. In Process Explorer use the "Find Handle or DLL..." command from the "Find" menu
   3. Enter in the name of the directory which is having trouble deleting
   4. A list of open files which match that name should be shown. Take some guesses and find which one is failing to be deleted. If the file is locked by a windows share, the process holding the file will be System
   5. Note down the directory which was left open

2. Download and install the Unlocker (Warning: Link removed, as it contains malware)

   1. Install Unlocker, disabling the option for Explorer extensions and other junk

3. Unlock the directory

   1. Open up a cmd window, and navigate to C:\Program Files\Unlocker
   2. From the cmd window, run Unlocker.exe "the-path-to-the-locked-folder"
   3. A dialog will pop up confirming the lock release. Use the unlock button to unlock the file

Now the directory should be unlocked, and can now be deleted.

回答2:

If you are admin on the server sharing the file over the network, you can use the Windows in-built feature:

1. Start → My Computer → Right-click → Manage gets you to the Computer Management console
2. In the left nav, navigate to Systems Tools → Shared Folders
3. You can view Shares, Sessions & Open Files here. This allows you to find out who has opened which files from which workstations.
4. Right-click on an item in the list to be able to remove the file lock.

Hope this helps.

回答3:

Try Process Hacker: https://wj32.org/processhacker/

Process hacker is like Process Explorer on steroids.

To find the offending process, press CTRL+F or click the "Find Handles of DLLs" button and search for the file name.

Once you find the file in the find handles dialog, you can simply right click the file there and choose "close". (at least for v2.39.124)

Older versions had a "terminator" option in the context menu of the process. Right click on the offending process --> Miscellaneous --> Terminator --> Select termination techniques. Note that some are possibly dangerous and may have unintended consequences.

回答4:

I've had similar problems, and none of these suggestions I've seen above look suitable for automated overnight builds (as the original poster implied) because they all require manual effort to hunt down and kill the locks.

The only method I've tried that seems to work reliably is to remove the share itself, make the build, then add the share back. Here's one way of removing the share automatically:

D:\Projects>net share Projects /DELETE /Y

Users have open files on Projects. Continuing the operation will force the files closed.

Projects was deleted successfully.

(NOTE: Creating the share again automatically can be a pain if the privilege groups you need to give it are messy.)

回答5:

Another option is, starting from Windows Vista, to use the Windows tool built into the system:

monitor resources: perfmon.exe /res

Extracted from: Http://www.sysadmit.com/2017/06/windows-how-to-know-that-process-has-open-a-file.html

回答6:

The way i do it is by using both OpenFiles.exe and Handle.exe You can run them in any order and you will have your resource fully unlocked.

OpenFiles: to disconnect File Sharing sessions

Handle.exe: to release any open handles (don't try to close handles belonging to pid4, since that's the system process)

You can automate this by using powershell, batch, or any language of your choice.