[lug] Interesting Common File Locking Problem

Zan Lynx zlynx at acm.org
Fri Mar 5 18:14:13 MST 2004

I spent some time figuring this one out.  I spent a few hours scratching
my head over this one.  I thought I would share for any of you
programmers out there.  Also, I just have to vent the frustration build
up to _someone_, or it'll bother me all weekend!  Heh.

Some programs appear to lock files using this method:

- open the file, get a file descriptor.
- lock the file descriptor.
- write data into a temporary file.
- optionally fsync the data to ensure it is really in there.
- rename temporary into real file name, which deletes the original,
which removes the lock.

At first glance, this looks reasonable and safe.  What I discovered is
that this can happen:
- ProgA opens the file, get a file descriptor.
- ProgB opens the file, gets a file descriptor.
- ProgB locks the file descriptor.  Now ProgA is waiting...
- ProgB creates temporary file, writes data into it.
- ProgB now renames temporary to real name.
- ProgB unlocks, closes, exits, etc.
- ProgA finally gets its lock!  Yay for ProgA!
But wait!  What lock is this!?
Could it be a lock on the now removed original file!?  The file ProgB
just deleted by renaming over it?
Why Yes!  It could!

Does anything stop ProgC from coming along and getting a lock on the
file name?
Why No, nothing does!  Because ProgA's lock is on a file that no longer
has that name!  In fact, ProgA's locked file no longer has any name!

And then does it stop there?  No indeed!  Because ProgC has the lock on
the file name, it assumes no one else is using the file.  Now, using the
same temporary file name ProgA is also using, ProgC goes ahead to
truncate and write into the temporary file.  What does this lead to?  Me
getting large chunks of zeros in my mail client spool file.

Bad multi-threaded Evolution!  Bad!
Zan Lynx <zlynx at acm.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.lug.boulder.co.us/pipermail/lug/attachments/20040305/8e854a55/attachment.pgp>

More information about the LUG mailing list