Date: Wed, 21 Apr 1999 14:56:44 +0200 From: Graham Wheeler <gram@cdsec.com> To: hackers@freebsd.org Subject: Re: File locking problem Message-ID: <371DCB0C.286F5EA9@cdsec.com> References: <199904201821.OAA16150@lor.watermarkgroup.com> <371D97C4.B7EFA0B1@cdsec.com> <371DC775.BF2DF3EA@cdsec.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?371DCB0C.286F5EA9>