From owner-freebsd-current Fri Jul 7 21:43:50 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id VAA18192 for current-outgoing; Fri, 7 Jul 1995 21:43:50 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id VAA18060 for ; Fri, 7 Jul 1995 21:43:38 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id OAA14323 for freebsd-current@freebsd.org; Sat, 8 Jul 1995 14:39:07 +1000 Date: Sat, 8 Jul 1995 14:39:07 +1000 From: Bruce Evans Message-Id: <199507080439.OAA14323@godzilla.zeta.org.au> To: freebsd-current@freebsd.org Subject: Re: /etc/rc and "rm -f /var/spool/lock/*" Sender: current-owner@freebsd.org Precedence: bulk >> |Lock files suck. They should not be used at all, and the only client >> |that really needs them right now is mgetty. >> >> What if you wanted to run outgoing hylafax and outgoing >> 'ppp -auto' on the same port. >Open the callout device with O_EXCL. Erm, O_EXCL is useless for locking devices in FreeBSD. POSIX specifies the behaviour for open() with both O_CREAT and O_EXCL set. This behaviour is useless for locking of devices (it only works of the file doesn't already exist, and non-existent files aren't devices). The behaviour is implementation-defined if only O_EXCL is set. In FreeBSD, the behaviour is to ignore O_EXCL. FreeBSD provides the TIOCEXCL ioctl. This is not so good in theory (open() + ioctl() isn't atomic, so the locking can at best be advisory) and is worse in practice (the ioctl always succeeds and no advise is given about prior locking; also, the locking doesn't apply to root). Bruce