Re: install/56303: On a fresh installation, /tmp on sparc64 is not sticky

[Andreas Gustafsson <gson%gson.org@localhost>]

The following reply was made to PR install/56303; it has been noted by GNATS.

From: Andreas Gustafsson <gson%gson.org@localhost>
To: RVP <rvp%SDF.ORG@localhost>
Cc: gnats-bugs%netbsd.org@localhost,
    martin%netbsd.org@localhost,
    roland.illig%gmx.de@localhost,
    Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>,
    vezhlys%gmail.com@localhost,
    christos%NetBSD.org@localhost
Subject: Re: install/56303: On a fresh installation, /tmp on sparc64 is not sticky
Date: Thu, 26 Aug 2021 18:45:16 +0300

 RVP wrote:
 > >> Re: progress.c 1.24: This test which you modified is not needed:
 > >>
 > >>  	if (deadpid == -1 && errno == EINTR)
 > >>  		continue;
 > >>
 > >> By ths point all read/writes have finished, and `outpipe[1]' has
 > >> been closed. So you can stop the progress bar code right after the
 > >> `while (1)' loop and no interrupts can occur. This is what my
 > >> initial patch did.
 > >
 > > Closing outpipe[1] eliminates one source of signals, but I don't see
 > > any obvious way of proving that there can be no others.
 > 
 > Not sure what you mean here: Only caught signals (ALRM and PIPE--but the
 > PIPE handler causes a termination) can cause wait() to return an EINTR.
 > If the progress bar is turned off, and there are no writes, wait() can't
 > come back with a -1 and EINTR.
 
 Yes, _if_ the progress bar has been turned off at that point, but that
 is not currently the case.  It would be the case if we also applied
 one of your other changes, moving the progressmeter(1) call to before
 the wait() calls, but I don't think that change is a good idea; it
 would cause the progress command to indicate that the operation is
 complete before the "cmd" has actually finished, and the final
 transfer rate estimate would no longer account for the full execution
 time of the "cmd".
 
 > The diff is slightly large, but, most of the changes are simple, obvious
 > ones, and the core logic is practically the same, so hardly a wholesale
 > replacement...
 
 By "wholesale replacement", I was referring to sending a complete
 source file as opposed to patches.
 
 > On Fri, 20 Aug 2021, Christos Zoulas wrote:
 > > That's a good change, replacing a non-portable ioctl call with a posix 
 > > terms function call.
 > 
 > That was the intent, yes.
 
 Since Christos supports that change, perhaps you can ask him to commit it.
 In any case, it is outside scope of the present (closed) PR.
 -- 
 Andreas Gustafsson, gson%gson.org@localhost