Don’t get me wrong, if you are not comfortable with the command line and a GUI is your proverbial “cup o’ tea” please continue (or call your sys admin/consultant).  This is just additional use of resources, registry entries, and mess.  My thoughts, personally.

Now, for those sys admins out there that prefer the command line you already know this so I apologize if today’s “tech tip” seems a yawn.

NET FILE

The next time you wonder where your file locks are use the command and enter:

NET FILE

from a command line (and these days you could use PowerShell … hint hint) and get a list of your files with(out) locks, who owns the lock(s), and their ID.  It is important to note their ID.

Why should you care?

Well we have many applications out there that if there is a lock on a key file, log, or executable, they will fail causing the application to fault.  Further investigation will find a lock on a file.  May people will instead reboot a server, dismount a share, or just outright blame an application.  Though sometimes these work these solutions are extremely disruptful to a production environment.

So instead, at a command line I use:

NET FILE (ID) /close

Now you know why it was important to know the ID’s of those locking a file.

Added caveat, if after a close the NET FILE shows a user continually locking on the file, have them reboot.  more than likely they have an open connection such as an explorer window open to the folder/file in question.