From owner-freebsd-hackers Wed Apr 21 5:59:20 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 77F25151B4 for ; Wed, 21 Apr 1999 05:59:15 -0700 (PDT) (envelope-from gram@cdsec.com) Received: (from nobody@localhost) by citadel.cdsec.com (8.9.3/8.9.3) id OAA26469 for ; Wed, 21 Apr 1999 14:56:46 +0200 (SAST) Received: by citadel via recvmail id 26409; Wed Apr 21 14:56:18 1999 Message-ID: <371DCB0C.286F5EA9@cdsec.com> Date: Wed, 21 Apr 1999 14:56:44 +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> <371D97C4.B7EFA0B1@cdsec.com> <371DC775.BF2DF3EA@cdsec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Graham Wheeler wrote: > > 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). I have now found the problem - it is a race between the process which is reading the directory contents and the one which is unlinking the file. The one that reads the directory gets the name of a file that the other is busy processing. The one doing the processing does the unlink and close, at which point the one reading the directory does an open. The problem is that it does the open with both read and write permission, and as a consequence ends up creating a new empty file with the old name. I'm not quite sure how I'm going to solve this one yet, but at least there is now a rational explanation. -- 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