Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Click here to return to the 'How to hide all .plist.lockfile files' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
How to hide all .plist.lockfile files
Authored by: scooby509 on May 19, '12 01:36:34AM
lockfiles are a standard Unix technique for locking with the "flock" system call, and you can verify this quite easily:

cd ~/Library/Preferences
perl -MFcntl=:flock -e 'open FH, "<", ""; flock FH, LOCK_EX; <STDIN>;' 

(I just tested with the Kindle app, anything should work.)

That will open the file, obtain a lock, and then wait for you to press enter. Launch the application or somehow cause it to access that preferences file, it will hang. When perl exits, it will close the file, thus releasing the lock. The application will continue to launch normally. (Incidentally, if you try to run this while the app has the file locked, perl will hang waiting for the lock, ctrl+C should interrupt it.)

I'm actually a little surprised that Apple chose to do this since writing to a temporary file and moving that into place avoids corruption. To prove this, in one terminal:

echo apple > foo
perl -e 'open FH, "<", "foo"; <STDIN>; print <FH>;'

Don't press enter just yet. In anther terminal do this:

echo banana > bar
mv bar foo

Now press enter in the first terminal, you'll see "apple". In fact, you can try something similar with a gigabyte sized file, and it still works. The reason is that Unix is based on inodes, and each directory entry is really a link to an inode. In addition, a filehandle that a program gets is also a link to an inode. When we did "mv bar foo", we made foo point to the content "banana", but the program's filehandle still pointed to the old inode, so it saw "apple" instead. That's why writing to a temporary file and using "mv" works so well: programs only see one consistent version of the file.

[ Reply to This | # ]