From owner-freebsd-hackers Wed Apr 21 2:20:52 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from citadel.cdsec.com (citadel.cdsec.com [192.96.22.18]) by hub.freebsd.org (Postfix) with ESMTP id D17FC14DDB for ; Wed, 21 Apr 1999 02:20:34 -0700 (PDT) (envelope-from gram@cdsec.com) Received: (from nobody@localhost) by citadel.cdsec.com (8.9.3/8.9.3) id LAA13560 for ; Wed, 21 Apr 1999 11:18:05 +0200 (SAST) Received: by citadel via recvmail id 13499; Wed Apr 21 11:17:27 1999 Message-ID: <371D97C4.B7EFA0B1@cdsec.com> Date: Wed, 21 Apr 1999 11:17:56 +0200 From: Graham Wheeler X-Mailer: Mozilla 4.08 [en] (X11; I; FreeBSD 2.2.8-RELEASE i386) MIME-Version: 1.0 To: hackers@freebsd.org Subject: Re: File locking problem References: <199904201821.OAA16150@lor.watermarkgroup.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Luoqi Chen wrote: > > > What exactly happens when a process obtains an exclusive lock on > > a file and then forks? Does the lock get removed only after both > > processes have closed the file, or after either one of them closes it? > > And if the latter, is there a way I can get around this? > > > Try using the POSIX style fcntl(2) lock instead? I need the open and lock to be atomic. I am currently trying to write a small program which replicates the problem I am having so I can post it. Currently everything works in the small program (as it does when I run the real program), but a client sees the failures I reported every now and then (about one failure per thousand files processed). I should mention I am not explicitly unlocking the file, but am relying on it being unlocked upon the last close. This appears to be the correct approach based on the flock, open and close manual pages. I am also relying on the file being removed upon the last close due to the call to unlink that happens before the last close. However, the behaviour we are seeing seems to indicate that on rare occasions, after the last close, the parent process is somehow managing to open and lock the file again, even though it cannot read anything (the first fgets() fails and feof() gets set). If the problem was that my code was buggy, and unlink() wasn't being called, then there would be no reason for the fgets() to fail. So it seems that although my assorted processes are doing things in the order: ... child:unlink() child:close() // and unlock parent:open() // and lock - should not succeed due to unlink parent:fgets() // should never occur as open() should fail ... there is some kind of race happening between the file being removed by the unlink and the parent:open() - the parent:open() is succeeding when it shouldn't, and then the fgets() is failing (which it shouldn't if the open was successful). -- Dr Graham Wheeler E-mail: gram@cdsec.com Citadel Data Security Phone: +27(21)423-6065/6/7 Firewalls/Virtual Private Networks Fax: +27(21)24-3656 Internet/Intranet Network Specialists Data Security Products WWW: http://www.cdsec.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message