[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Need Help] About file lock in Debian Sarge

[please don't top-post]

On Tue, Dec 22, 2009 at 02:31:16PM +0700, Muhammad H Hilman wrote:
> Wow, it's work
> but, must I change the code on my application that needed filelock?
> because, filelock code on that application stated as ubuntu command (just
> filelock)
> as far as I know debian command on filelock is (filelock-create)

I've never heard of filelock-create, I'm afraid.  A quick search
doesn't show it in any Debian package.

> can you tel me what's the different between (filelock-create) command and
> lockf() and fcntl()
> actually, I am still newbie on using Debian

This is probably off-topic for debian-devel.

File locking is /ideally/ done using advisory byte-region locking,
provided by the system calls fcntl(), lockf() and flock().  flock() is
deprecated (doesn't work over NFS, where the others do, as well as not
being SUS/POSIX).  flock() and lockf() are equivalent.  Both these
calls will allow one to lock some (or all) of the data in a given open
file.  But, they do require the file to remain open while you want to
prevent others modifying it.

For uses such as shell scripts, where each command runs a separate
process, byte-region locking doesn't always work due to the lock
being lost when the command terminates.  Here, we can use the
atomic property of open(2) with O_CREAT|O_EXCL to obtain exclusive
access to the file.  Since it's a file, it's preserved between
running each separate command.  But, it has the disadvantages of
· no automatic cleanup; the lock remains if the program terminates
  before it deletes the lock file
· needs logic to detect and remove "state" lockfiles; this includes
  checking that the program that originally created the lock file
  is still running, which can be tricky
· no differentiation between readers and writers (the others
  have separate read (shared) and write (exclusive) locks.  This
  means you can't have multiple readers, which will cause more
  lock contention, and hence potentially lower performance

liblockfile is a strange beast in some respects, being a C interface
to creating lockfiles.  However, a typical C program should in most
cases be using byte-region locks; it appears mainly used by MTAs
which also have an odd (unnecessary?) obsession with lock files.

As a general rule:

• If all your locking occurs in a single program and the locks
  don't need preserving when the program is not running, then
  byte-region locks are optimal

• If you are wanting locking during the execution of a shell
  script where locks need preserving between the execution of
  individual commands, then lock files are the only choice

As an example of how to do this totally wrong, see openoffice.org.
It creates lockfiles, where it should be using byte-region locks.
If it crashes while editing a file on one machine, or you copy a
directory containing an open file, and you try and open it on another
machine, it won't allow editing until you manually clean up the lock
files.  Totally stupid, and very user-unfriendly.

Hope this makes some sense.  If you have any other questions, then
debian-mentors or private mail is probably the way to go.  If you
provide some real details of what you are trying to do, you'll
get a more specific answer.


  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.

Attachment: signature.asc
Description: Digital signature

Reply to: