How to close all file handles under a given folder programatically?

Thanks for this. We've been having some issues with open file handles causing git checkouts to fail within our Windows-based Jenkins jobs and this helped correct the problem handily. I'll throw out the basics of the technique:

1. Install Handle.exe on the build node. I downloaded it from here http://technet.microsoft.com/en-us/sysinternals/bb896655, unzipped it and dropped Handle.exe under C:\Windows\System32 to ensure it would be available on the default %PATH%

2. Install the Jenkins pre-scm-buildstep plugin: https://wiki.jenkins-ci.org/display/JENKINS/pre-scm-buildstep. This allows us to define operations before the git plugin started reaching for potentially locked files.

3. Implemented the following batch command as a pre-scm build step:

   @echo off
   echo Cleaning up open file handles from %NODE_NAME%:%WORKSPACE%...
   for /f "tokens=3,6,8 delims=: " %%i in ('Handle /accepteula %WORKSPACE% ^| grep workspace') do echo Releasing file lock on E:%%k & handle -c %%j -y -p %%i
   

It appears to work nicely and definitely cuts down on spurious failures. I'll also note a couple gotchas I worked through:

• Handler.exe has an EULA that must be accepted the first time it runs. If you're running your Jenkins agent as a service under the Local System context, this is problematic because you can't log in as that user and accept it by hand. When we tried running it from the Jenkins job, the process just hung waiting for user input and it took a few minutes to figure out why. I solved this by running it from the Jenkins job using the /accepteula flag and I recommend anyone implementing this as an automated process do the same. This happens to be a registry setting under HKEY_CURRENT_USER\Software\Sysinternals\Handle and you can also set and unset it via regedit.exe if you need to manipulate it for a specific user, but the command line option seemed easiest.

• The Jenkins Batch step plugin executes batch code as if it were in a script rather than as a command line directive. Notice the escapes ( e.g. %%i, ^| ).

Thanks!

We use the following snippet to close file handle from users to our server. You may be able to modify it for your use.

rem close all network files that are locked
for /f "skip=4 tokens=1" %%a in ('net files') do net files %%a /close

Unlocker does claim it gives you this ability:

1. Simply right click the folder or file and select Unlocker

   

2. If the folder or file is locked, a window listing of lockers will appear

   

3. Simply click Unlock All and you are done!

I'm not sure if it supports command-line usage.

MalwareByte's FileAssassin performs similar actions, and does support command-line usage, so you should be able to script it pretty easily.

I create this little batch file to auto release all locks to xml file by my eclipse

@echo off
for /f "tokens=3,6,8 delims=: " %%i in ('handle -p eclipse e:\git\ ^| grep .xml') do echo Releasing %%k & handle -c %%j -y -p %%i

You need to download the handle utility from Microsoft site and grep utility from GnuWin32

If you don't need filter by file type, you can skip grep part like this:

@echo off
for /f "tokens=3,6,8 delims=: " %%i in ('handle -p eclipse e:\git\') do echo Releasing %%k & handle -c %%j -y -p %%i

Or if you don't need to filter locks by a particular program, just remove the eclipse process filter:

@echo off
for /f "tokens=3,6,8 delims=: " %%i in ('handle e:\git\') do echo Releasing %%k & handle -c %%j -y -p %%i

Remember to replace e:\git\ with your folder path.

If you're using PSTools, this will force close all open files recursively:

psfile \\serverName c:\path\toDatabase\ -c

Note that c:\path\toDatabase\ is the C: drive on \\serverName, not your local machine. This was unclear to me at first so I thought I'd point it out.

This is a brute force approach that's almost guaranteed to lose data, so use it with caution.

We have a badly cobbled together Access database that literally brings our company to it's knees on a regular basis (I had to fix it three times just yesterday).

The guy who normally handles this is on vacation for a couple of weeks and his instructions use a UI based approach (Start > Computer > Manage > Computer Management (Local) > Connect to another computer > System Tools > Shared Folders > Open Files > Close Open Files). WAY too many clicks when I can just run the above command & kick the entire company out of all the database files & start the Compact & Repair process (which I'm also working on a brute force scripted approach to).

The trick is staying ahead of the folks who immediately start to reconnect to the database as soon as it goes down. They're so used to this that it doesn't occur to them to file a bug against it, they just keep hammering the database until they get back in. I just keep booting them off until I've compacted & repaired the three dozen files that make up the database.