[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. Regards, Roger -- .''`. 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