Lockfiles and other plist file subtypes in OS X Lion
If you browse through the user library in OS X Lion, you may see a number of .plist.lockfile files in your preferences folder. Here is what these and other plist subtypes are all about.
When troubleshooting your system, or when attempting to mirror settings from one system to another, you may end up browsing through your user library, and specifically through the Preferences folder within it to copy preferences files for your applications. This procedure is fairly straightforward, but when browsing through your preferences folder you may see a few unexpected file types, including ones with strings of characters appended to the ends of them and in Lion a new "lockfile" type.
MacFixIt reader "Chris" wrote in, asking:
Can you please provide an explanation of the new plist.lockfile files in the Preferences folders in Lion? They seem to be created once the respective app was launched the first time.
What is their function?
If I want to copy the prefs of a given app to another volume manually, should I copy just the normal plist file (letting the plus.lockfile to be created there automatically), or should I copy both?
In addition to Chris' question, a number of other MacFixIt readers have asked about the accumulation of empty preference files in past versions of OS X, and have wondered what they are and whether it is safe to remove them.
Preferences files in OS X are stored in Apple's plist format, which is an XML file type that contains a specific set of tags and organization for application settings. The files can either be text files which will open readily in any text editor, or can be encoded in a binary format to make handling them more efficient. Regardless of these details, when a program writes settings to a plist file it uses Apple's standardized methods for doing so, by referencing central plist management commands and routines instead of using its own code for managing the preferences file format.
This makes it easier for the programmer to use the plist format, and also allows preferences to be standardized on the system instead of having numerous odd formats in your library folder from every developer out there.
Temporary plist files
Part of the way the system manages preferences files is a protection method for preventing corruption from happening if an error occurs when the system is writing preference files. For instance, if you are saving settings for a program and the system suddenly loses power, then the preferences file being written to may get corrupted and won't open properly when the system is restarted, which would result in all your settings being lost. To combat this, the system creates a temporary file to save the new settings, and when the file is properly saved, it then replaces the old file with the new one.
In OS X 10.6 or earlier, if you look in the preferences folder you may see a number of property list files with a string of eight characters after their names, such as the following:
All of the files with eight-character strings appended to their names will be 0KB in size, and are the temporary files that were used for a specific preference saving instance. The temporary file should be deleted automatically, but sometimes odd problems may result in them sticking around. The accumulation of these temporary preference files may have been corrected in Lion, but if you are running Snow Leopard or Leopard, then you will likely see them appear after a while of using your system. You can safely remove them from your system if they begin to accumulate over time.
Lockfiles in OS X Lion
This technique for securing preference file editing via parent programs is still present in Lion, but in addition Apple has implemented a new feature to limit preference file access by multiple parent programs, which is to use the lockfile type to flag whether or not a particular preferences file is in use.
When a program opens a preferences file, it will usually read from it (or write to it), and then close it right away since keeping it open will maintain a file-system "lock" on the file--file-system locks limit any further access to the file by other programs and system services while the one program is accessing it.
This standard practice of only locking a file temporarily ensures that if another program needs to access the file, then it can do so unless the first program is explicitly reading from or writing to the file. For example, you should be able to read or edit the iTunes preferences file using TextEdit even when iTunes is running (iTunes does not persistently hoard its preferences file).
While this preference file handling behavior is desired in OS X and maintained in Lion, Apple's new feature creates a "checkout" system by using the "lockfiles" that you see in the preferences folder. These files are generally used as semaphore (flagging) files to indicate whether or not the file they represent is in use by a program. For example, if you have a file called "test.txt" and open it, one way to indicate you have it open without keeping a filesystem lock on it is to make a file next to it and call it "test.checkout," and then delete the "checkout" file when you are no longer using the "test.txt" file. If the checkout file is present, then you know the file "test.txt" is in use, even though technically you could direct another editor to open test.txt if you wanted to (after all, the file itself is not locked).
Apple has done a similar thing with the lockfiles in OS X Lion, but instead of merely creating an indicator file that shows up when you open or check out a preferences file by launching its respective application, OS X creates a persistent lockfile. The file is merely a directory entry so it takes no space on the hard drive, and when you open the program the lockfile is opened but not released, so a persistent file-system lock is kept on it when the program is open. You can see this by trying to delete the ".lockfile" when you have the program open versus when you have it closed--you can only delete it when the program is closed.
Similar to the checkout system described above, if another program is launched that tries to access the same preferences file, then it will first try to capture the lockfile but will be unsuccessful, so the preferences handling system should not allow that program to interact with this particular preferences file.
This system may seem a bit unnecessary; however, there are some situations where multiple instances of programs can be launched (Programs in OS X normally only open one instance, but can be altered to open multiple), and having them running simultaneously may result in odd handling of preference files (overwriting of saved settings, or corruption) if they are all interacting with one preferences file. Therefore having a lock system will prevent such problems and keep preferences handling tidy and neat.
The lockfile is just an empty file entry in the volume's directory, so if you are transferring preferences from one system to another, or from one account to another on the same system, then you can still do so by copying the .plist file and leave the .lockfile where it is on the file system. The lockfile can also be safely removed at any point (provided it is not in a locked state), though this would be pointless to do because the system will just recreate it the next time the respective program is launched. Perhaps Apple should keep these lockfiles hidden, but then again in Lion the whole user Library is hidden by default.