From owner-freebsd-arch@FreeBSD.ORG Sun Jun 25 15:10:48 2006 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C19316A40F for ; Sun, 25 Jun 2006 15:10:48 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D90243D58 for ; Sun, 25 Jun 2006 15:10:42 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout2.pacific.net.au (Postfix) with ESMTP id 6E73310B021; Mon, 26 Jun 2006 01:10:41 +1000 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k5PFAca4005207; Mon, 26 Jun 2006 01:10:39 +1000 Date: Mon, 26 Jun 2006 01:10:38 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Andrew Reilly In-Reply-To: <20060625020154.GA89358@gurney.reilly.home> Message-ID: <20060626002658.A65226@delplex.bde.org> References: <20060625011746.GC81052@duncan.reilly.home> <20060625013110.GA62237@troutmask.apl.washington.edu> <20060625020154.GA89358@gurney.reilly.home> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Steve Kargl , freebsd-arch@FreeBSD.org Subject: Re: What's up with our stdout? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jun 2006 15:10:48 -0000 On Sun, 25 Jun 2006, Andrew Reilly wrote: > On Sat, Jun 24, 2006 at 06:31:10PM -0700, Steve Kargl wrote: >> On Sun, Jun 25, 2006 at 11:17:46AM +1000, Andrew Reilly wrote: >>> >>> The question is: what's wrong with our shell or stdout that a >>> program (nbcat in this case) can't fcntl-lock the file opened >>> for output? Is this related to the /dev/stdout@ -> fd/1 files >>> that we have? Seems like a shortcoming to me... >> >> Have you reviewed the nbcat source code to determine >> what wrong assumptions it is making about stdout and/or >> fcntl? > > What's to assume? The shell should make file descriptor 1 be > the output file, opened for writing or append, depending on > whether you used > or >> on the command line, no? > > NetBSD's cat.c just says: > > if (lflag) { > stdout_lock.l_len = 0; > stdout_lock.l_start = 0; > stdout_lock.l_type = F_WRLCK; > stdout_lock.l_whence = SEEK_SET; > if (fcntl(STDOUT_FILENO, F_SETLKW, &stdout_lock) == -1) > err(EXIT_FAILURE, "stdout"); > } > > Looks OK to me. > > The file opened for stdout is definitely a normal file. F_SETLKW > should succeed or wait in this case, IMO. > > Our stdout(4) doesn't say anything that looks ominous, but I > admit to being far from a guru on the issue. I don't even > understand how those /dev/fd devices interact with the system, > or why they're there (other than as a way to fake a "-" file > argument to programs that don't normally have one). I don't see > how they're relevant in this case though. This doesn't seem to have anything to do with stdout. F_SETLKW just seems to be broken on all regular files (and thus is unsupported for all file types). The above works under the modified version of FreeBSD-5.2 that I use, but it fails with the documented errno EOPNOTSUPP under at least FreeBSD-6.0-STABLE. Replacing STDOUT_FILENO by fd = open("foo", O_RDWR) gives the same failure. Replacing FSETLKW by FSETLK or F_GETLK gives the same failure. The errno for irregular files seems to be broken in different ways for all cases, but the differences only depend on the file type, not on the version of FreeBSD. At least for F_GETLK: 5.2+, 6.0 on tty input: fails with bogus undocumented error EINVAL 5.2+, 6.0 on pipe input: fails with bogus undocumented error EBADF The Minix 1.6.25+ regression tests for F_*LK* detect the regression but don't check for the bogus errnos. They start with simple checks like the above and quit before getting to more complicated tests when locking never works. I ran them only under FreeBSD_6.1=PRERELEASE. Bruce