When a file is opened by a program, a filesystem lock is placed that prevents it from being accessed by another program. However, most programs in OS X will only truly “open” a file as a brief step in order to read its contents into memory. The file is then technically closed so it may be accessed elsewhere. Further interaction with the file will result in another quick “open” followed by the instructed manipulation right before the file is closed again, and computing goes on.

Despite this, there are some programs that will maintain a lock on a file when reading its contents in memory. Whether by error or for a specific reason based on the program’s coding, this will restrict further interaction with the file, resulting in errors about a file being locked, owned, in use, or otherwise not accessible.

The easy solution to this problem is to quit the offending program, and thereby release the lock held on the file, but identifying the program can be difficult, especially if the process is some background task. To manage this, we are going to drill down into the Terminal and make use of a few commands:

• lsof: this lists all files currently in an “open” state.
• fuser <filename>: this script runs lsof, but gives cleaner output limited to the specified file.

The “lsof” command can be run by itsel to list all open files, but you can limit the command’s output by piping the output to the “grep” command and entering text to use as a filter, such as the following to limit the output to lines that contain the word “myfile”:

lsof | grep myfile

Alternatively you can use “fuser” which is a perl script that runs on a specified file to see if it is open, and if so then by which process ID:

fuser /path/to/file

Note that you can run this easily by just typing “fuser” followed by a space, and then dragging your desired file to the Terminal to enter its full path, as opposed to having to type it manually.

With the process ID information we can now look in Activity Monitor and search for the given PID to locate it. While we can use Terminal commands such as “ps” or “top” to do this, but we’re using Macs here and Activity Monitor will suffice.

First try to identify if the program is a user application (ie, one in the Applications folder) and try quitting the program in OS X, if possible. If not, then try the following approaches in sequence for a progress from encouraging the program to relaunch gently to hard-quitting it. For all of these you can select the program in Activity Monitor, and then choose “Send Signal to Process…” from the Edit menu followed by choosing one of the following signals. You can optionally run the corresponding Terminal command:

1. Hangup (SIGHUP)

This will allow you to gently encourage the program to release its resources. In many cases programs that receive this will just refresh their configurations and keep running. With the offending program’s process ID from the above commands, you can signal it to hang up using the following Terminal command:

kill -1 PID

2. Terminate (SIGTERM) or Interrupt (SIGINT)

These are your standard quit, where the system requests a program shut down. These allow the program to save preferences, files, and other resources before shutting down on their own accord. The Terminate signal is the default used by the “kill” command (that is, if no options are specified), and is also what is invoked by OS X when you quit a program. It is here to give the same functionality for background tasks, and can be invoked either with Activity Monitor or by the following kill options in the Terminal:

kill PID (Terminate)
kill -15 PID (Terminate)
kill -2 PID (Interrupt)

3. Kill (SIGKILL)

If you attempt to kill or quit a process and it refuses to do so, then it is likely that you have been sending it a Terminate or Interrupt signal, for which the system allows processes to override under some circumstances. To get around this, you need to hard-kill the program, which can be done by sending the SIGKILL command. To do this in the Terminal, run the following version of the kill command:

kill -9 PID

When the program that has the lock on the file has been quit, you should now be able to open the file in the program of your choice. Keep in mind that sometimes an odd problem or two may prevent even these approaches from fixing the issue, in which case you can always restart your computer as a last resort.