race condition in mv -i (Was: race condition with set -C)

2016-11-07 17:19:13 +, Geoff Clare: [...] > > Is that allowed by POSIX? > > No; the standard clearly says "The mv utility shall perform actions > equivalent to the rename() function" in step 3. Well, when moving across file systems, it already does something very different from an atomic

Re: macOS 10.12, broken PTHREAD_CANCEL_DISABLE and UNIX certification

Given frame 6 and 7, it looks like write is calling pthread_exit directly, rather than pthread_cancel, so would be where the bug is, unless write is required to exit for that particular circumstance. If it has to exit, then the setup code necessary to avoid it is missing from the main thread's

What does the standard say about whether assignments are visible for subsequent expansions in a simple command without a command name?

Hello, the current shell standard says in Section 2.9.1: --- If no command name results, variable assignments shall affect the current execution environment. If the command name is not a special built-in utility or function, the variable assignments (...) shall not affect the

Re: [1003.1(2013)/Issue7+TC1 0001016]: race condition with set -C

Op 07-11-16 om 03:55 schreef Shware Systems: > To last question, yes, but the effects are supposed to be documented so > generic guard code that may invoke platform specific pre-ln attempt > handling can be written. This is a compromise to disqualifying a system > that defines additional file

Re: [1003.1(2013)/Issue7+TC1 0001016]: race condition with set -C

2016-11-02 13:32:44 +, Martijn Dekker: [...] > If both 'mkdir' and 'ln' operate atomically, there could be a safe > workaround for creating a regular file directly under /tmp. It would > involve creating a (very) temporary directory under /tmp using 'mkdir > -m700', then creating the file

Re: [1003.1(2013)/Issue7+TC1 0001016]: race condition with set -C

2016-11-07 15:57:25 +, Stephane Chazelas: > 2016-11-07 15:40:15 +, Geoff Clare: > [...] > > > Same problem with "mv" (which I think would work just > > > as well (with LC_ALL=C mv -i < /dev/null 2> /dev/null)) > > > > No, mv -i doesn't work just as well - it has a race condition. > > If a

Re: [1003.1(2013)/Issue7+TC1 0001016]: race condition with set -C

2016-11-07 16:20:08 +, Geoff Clare: [...] > > How so? "mv -i" with /dev/null as stdin ("no" answer to prompt) > > is not supposed to remove anything. > > Only if it prompts. If the existence check fails, mv will not > prompt and will just call rename(). OK, sorry, I had assumed rename()

Re: [1003.1(2013)/Issue7+TC1 0001016]: race condition with set -C

Stephane Chazelas wrote, on 07 Nov 2016: > > 2016-11-07 16:20:08 +, Geoff Clare: > [...] > > > How so? "mv -i" with /dev/null as stdin ("no" answer to prompt) > > > is not supposed to remove anything. > > > > Only if it prompts. If the existence check fails, mv

Re: [1003.1(2013)/Issue7+TC1 0001016]: race condition with set -C

Stephane Chazelas wrote, on 07 Nov 2016: > > 2016-11-07 16:57:34 +, Stephane Chazelas: > [...] > > OK, sorry, I had assumed rename() would fail if the target exits > > already. > [...] > > BTW, in the spec of link(2): > > [EEXIST] > The

Re: [1003.1(2013)/Issue7+TC1 0001016]: race condition with set -C

Stephane Chazelas wrote, on 07 Nov 2016: > > 2016-11-07 15:40:15 +, Geoff Clare: > [...] > > > Same problem with "mv" (which I think would work just > > > as well (with LC_ALL=C mv -i < /dev/null 2> /dev/null)) > > > > No, mv -i doesn't work just as well - it has

Re: [1003.1(2013)/Issue7+TC1 0001016]: race condition with set -C

2016-11-07 16:10:01 +, Stephane Chazelas: [...] >mv -i a b < /dev/null 2>&- > > seem to work with GNU or Solaris10 mv (in that it returns with > an error when a prompt fails to be issued) but not with > FreeBSD's [...] Sorry, I messed up my tests on Solaris. Solaris /bin/mv doesn't issue

RE: [1003.1(2013)/Issue7+TC1 0001016]: race condition with set -C

> -Original Message- > From: Geoff Clare [mailto:g...@opengroup.org] > Sent: Monday, November 07, 2016 5:20 PM > To: austin-group-l@opengroup.org > Subject: Re: [1003.1(2013)/Issue7+TC1 0001016]: race condition with set > -C > > That seems to be in contradiction with it calling the link()

Re: [1003.1(2013)/Issue7+TC1 0001016]: race condition with set -C

Stephane Chazelas wrote, on 07 Nov 2016: > > BTW, there's an issue in the spec for "mv": > > > EXIT STATUS > > > > The following exit values shall be returned: > > > >  0 > > All input files were moved successfully. > > >0 > > An error occurred.

Re: [1003.1(2013)/Issue7+TC1 0001016]: race condition with set -C

2016-11-07 16:57:34 +, Stephane Chazelas: [...] > OK, sorry, I had assumed rename() would fail if the target exits > already. [...] BTW, in the spec of link(2): [EEXIST] The path2 argument resolves to an existing directory entry or refers to a

Re: [1003.1(2013)/Issue7+TC1 0001016]: race condition with set -C

No, there is no app dir structure mandated by POSIX. That is considered an administrative issue outside of the base POSIX scope, and is generally covered by packaging conventions like DEB and RPM as de facto standards. I don't think any platform implemented the proposed 1003.1j standard. Only

Re: Intended difference between waitpid() and waitid() ??

Date:Sun, 6 Nov 2016 23:19:30 -0500 From:Shware Systems Message-ID: <1583d033695-e5e-e...@webprd-a49.mail.aol.com> | I believe the difference | is to take into account a pid may be both a specific process id and | process group id for a

Re: Intended difference between waitpid() and waitid() ??

Date:Mon, 7 Nov 2016 09:51:32 + From:Geoff Clare Message-ID: <20161107095132.GA14686@lt.loopback> | I am fairly certain the difference is not intentional. OK, thanks. | All certified UNIX systems give an ECHILD error from waitid() |

[1003.1(2013)/Issue7+TC1 0001020]: snprintf: the description of the n argument conflicts with ISO C

A NOTE has been added to this issue. == http://austingroupbugs.net/view.php?id=1020 == Reported By:ch3root Assigned To:

Re: Intended difference between waitpid() and waitid() ??

Robert Elz wrote, on 06 Nov 2016: > > The spec (C165) for wait() (though this is only relevant to waitpid()) > says ... > > If waitpid( ) was invoked with WNOHANG set in options, it > has at least one child process specified by pid for which status > is not