Date: Mon, 26 Jun 2006 01:10:38 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Andrew Reilly <andrew-freebsd@areilly.bpc-users.org> Cc: Steve Kargl <sgk@troutmask.apl.washington.edu>, freebsd-arch@FreeBSD.org Subject: Re: What's up with our stdout? Message-ID: <20060626002658.A65226@delplex.bde.org> In-Reply-To: <20060625020154.GA89358@gurney.reilly.home> References: <20060625011746.GC81052@duncan.reilly.home> <20060625013110.GA62237@troutmask.apl.washington.edu> <20060625020154.GA89358@gurney.reilly.home>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060626002658.A65226>