From: Jilles Tjoelker <jilles@stack.nl>
To: Eduardo Bustamante <dualbus@gmail.com>
Cc: Denys Vlasenko <vda.linux@googlemail.com>,
Herbert Xu <herbert@gondor.apana.org.au>,
dash@vger.kernel.org
Subject: Re: Bug? "fstat64(f, &sb) < 0 && S_ISREG(sb.st_mode)"
Date: Wed, 26 Oct 2016 23:43:09 +0200 [thread overview]
Message-ID: <20161026214309.GA78242@stack.nl> (raw)
In-Reply-To: <CAOSMAutbPNXKy_GVHDWiJv8=LRDnMPNBrsN1RgwYGVL4gJTwmg@mail.gmail.com>
On Tue, Oct 25, 2016 at 12:13:51PM -0500, Eduardo Bustamante wrote:
> I see the change was introduced here
> http://git.kernel.org/cgit/utils/dash/dash.git/commit/?id=f78674ed6f95b594dcac0e96d6a76c5f64aa2cbf,
> by importing code from FreeBSD's sh.
> What I find interesting is testing the contents of 'sb', when the
> fstat64 call failed. FreeBSD's code has the opposite:
> https://github.com/freebsd/freebsd/blob/master/bin/sh/redir.c#L200,
> i.e. they do:
> if (fstat(f, &sb) != -1 && S_ISREG(sb.st_mode)) {
> BTW, that code was introduced here:
> https://github.com/freebsd/freebsd/commit/e3cb9d1015e8283f4f9d116cf50f510741f8c0dd
The FreeBSD code is how it was intended to be. I don't know how the dash
bug was introduced. The bug only appears when a parallel actor replaces
an openable non-regular file (such as a symlink to /dev/null) with a
regular file and may cause corruption of the file.
As noted on austin-group-l recently, the code does suffer from an issue
where a noclobber open may fail if a parallel actor deletes a
non-regular file (stat reports non-regular file, open fails). Many other
shells have this issue, though.
> Also, the way the open is performed has an interesting consequence,
> i.e. the redirection operation on a FIFO blocks until something is
> written to the FIFO:
> hp% dash -Cc 'rm ff; mkfifo ff; echo a > ff'
> ^Cdash: 1: cannot create ff: Interrupted system call
> It seems to be the same case for mksh, ksh93, posh, pdksh. Not that it
> matters though.
Blocking is intended behaviour when opening a fifo without a
counterparty. It can be used to good effect for synchronizing processes,
sometimes even without transferring any data.
--
Jilles Tjoelker
next prev parent reply other threads:[~2016-10-26 21:43 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-25 15:33 Bug? "fstat64(f, &sb) < 0 && S_ISREG(sb.st_mode)" Denys Vlasenko
2016-10-25 17:13 ` Eduardo Bustamante
2016-10-25 17:19 ` Eduardo Bustamante
2016-10-26 21:43 ` Jilles Tjoelker [this message]
2016-10-27 0:35 ` Eduardo Bustamante
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20161026214309.GA78242@stack.nl \
--to=jilles@stack.nl \
--cc=dash@vger.kernel.org \
--cc=dualbus@gmail.com \
--cc=herbert@gondor.apana.org.au \
--cc=vda.linux@googlemail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).