From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, HTML_MESSAGE,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 12510 invoked from network); 9 Oct 2020 20:48:19 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 9 Oct 2020 20:48:19 -0000 ARC-Seal: i=1; cv=none; a=rsa-sha256; d=zsh.org; s=rsa-20200801; t=1602276499; b=Er9by6R43ymrk06do7nfd0xjp14RkXZ7JgT4SgxF1xAjR1WFbscHD2OX4n21Miq/s6U83XWU5y ip3AL/VqrkfkwjQbq59fuz1M/sWhhpRGs/IkrmPHEZAfLWp3D0ngTrhKFvS5dwuuzC2eNrsYFy fkvxIdQOd4R30EnpxsL75Ug2hesJopdlogkGPeAp3NV2ABVIeGWtJrt2Cu2CUHdfiuMuUgC3E0 L0UfPrbNGK0TMU3/wYnfraVl1LoYvljRN10GrFO5u3+6mHXwdpvLunLjyCv56wit0n2QYvHyvZ jZx4LAGDccR+0ZxlFvx9Ov57kEcBq8o+mSOBCMfd4wdPuQ==; ARC-Authentication-Results: i=1; zsh.org; iprev=pass (mail-oi1-f171.google.com) smtp.remote-ip=209.85.167.171; dkim=pass header.d=brasslantern-com.20150623.gappssmtp.com header.s=20150623 header.a=rsa-sha256; dmarc=none header.from=brasslantern.com; arc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed; d=zsh.org; s=rsa-20200801; t=1602276499; bh=P8PLs95EupRVhWDu2I8QwYZtFmZSdp95TSspWBNGcFA=; h=List-Archive:List-Owner:List-Post:List-Unsubscribe:List-Subscribe:List-Help: List-Id:Sender:Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:DKIM-Signature:DKIM-Signature; b=ogWpzgNFkxWwVYmLPhr5jMuDQYWvYhjAEHv4av8+wJg4/eWZjKC2hOt0p45XIL/wwinJRyY4ws gpaby5YIrecztCaWn6DfA3sWKWDwuLlOHufZkQ0JGHunUSkzLdFjARL+KXky2okIeRJGyJQNJ/ epGgitsCNg5ej76id/jyVF7j5QisWCKYFVY57rSPAcUf20BAq9JWtFq9T22Pz4j5YKwAzftPuq clgi8/YTaIjZwcqduLvgSwzbZmcHp0w+cPXWyNleWUesu9Ty4PZxDam4PAggtftnvSVRXvRewS r0pGe3xgNnrw2ADA47okbzHS+ByfnJk40yUyj/IAo8sXsA==; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=zsh.org; s=rsa-20200801; h=List-Archive:List-Owner:List-Post:List-Unsubscribe: List-Subscribe:List-Help:List-Id:Sender:Content-Type:Cc:To:Subject:Message-ID :Date:From:In-Reply-To:References:MIME-Version:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID; bh=JLivpwznZ24FQYwYxZi5kO08hzzxE6UgxmOlYEpWtMw=; b=uclcnIhv7np8QPe1Ksw5aTK6fr tchcbOgiWDbZ0oGvQ93flKQjACBQkEu/+SUtjsqnERLfAOJHVGrBqx46ZqXF7fpyuYksJ5mxWxNDA xXTz89HWOh18WPxf+q16BcQNp08MrAnTd+5C1hQUgYLjggSR0Gzf6Pzjd5+IOslhBu3u0HskZB6M7 fLt0X9e4wXPnd6ZhK/BIv/pHgu9shYBY/XwU+OgVVofgdhwqOdFu10Pb/gcD2vsgz/U64eKNBB7fg mkpxAnhRHYbmtxZ+O1bIJzIcf8M4UDj7fJuyHIS+kaJTruwG2dX+VVFraYT9L9559EJfJoPSBGW+4 YsDgFaIA==; Received: from authenticated user by zero.zsh.org with local id 1kQzJJ-000IVQ-Tu; Fri, 09 Oct 2020 20:48:17 +0000 Authentication-Results: zsh.org; iprev=pass (mail-oi1-f171.google.com) smtp.remote-ip=209.85.167.171; dkim=pass header.d=brasslantern-com.20150623.gappssmtp.com header.s=20150623 header.a=rsa-sha256; dmarc=none header.from=brasslantern.com; arc=none Received: from mail-oi1-f171.google.com ([209.85.167.171]:46931) by zero.zsh.org with esmtps (TLS1.3:TLS_AES_128_GCM_SHA256:128) id 1kQzJ3-000IN3-VN; Fri, 09 Oct 2020 20:48:02 +0000 Received: by mail-oi1-f171.google.com with SMTP id u126so11484726oif.13 for ; Fri, 09 Oct 2020 13:48:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JLivpwznZ24FQYwYxZi5kO08hzzxE6UgxmOlYEpWtMw=; b=qlOlUPo5RQBUDbMpGfjnboJexGu7++Ck34FFxSSIgJdT9FQD+zb2rfQ6IUody98lcQ UKORKf4TYtKPporD97fC6RbIPE7uMMsFJHGvffPlLPI+4jEv8Ev0LQroqUroZlaldHy/ LncX5t8itrgU4qWJRnlTR/QQqyCmtxIwY7v7cX57cU7j2ZqDT0HuiQFZTQi6PIG0O/Wo 3nYqcIQTKIhwsSqvmHjs9SHnzG2h3QfUm+rpgNRjYx6+HzwRkJZXkpLCIGMXtSaeMKif AYcLRsonh7tC7CU+Crf9lX3OopeIyXxp1O+IopvbFkSmVNeAkpVEBM0adf0n+s/lXnSi Mnlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JLivpwznZ24FQYwYxZi5kO08hzzxE6UgxmOlYEpWtMw=; b=J9Sq2t99kKkdbOVaqQgozO0DuCZckCxTzExcX15jwxCJWit6eInW9+I8QLxQBtdz+f uIuvrFP8iIbIJe/x8BhmJ3JkiFXE3cBjV8uS6Py0dhatv298IBCkwop/0rWpV9wLIOxn I7XKyQS/4QbMiL1s7vlA+pWPWVmhGMp2RmOmN24d4jkpcl6XkaGBLqcWmwu5uWL4MoX9 0ds2RLU2sSNYKFHCVRWPzpW5CHua9dRcxh6SpYeyWz3kLgtmpJX4hroXh/1jyc2vSxiY jS315UmsAOr21EYCoQcRTde7KJQ59qIxp1QS30RE1ZwzMjljhD75K26w/dX87yrJPrhV CAkw== X-Gm-Message-State: AOAM530jLJQALxpTJWppqeZcZqe8gsdTKe00ZdHoE1+Lbi+QmDFkb1Hu JtpssqaZI6/PhkeqgPeSY8a46KOhdAeusYf3tVOjiND8OJ8JQw== X-Google-Smtp-Source: ABdhPJx2myIH546ExJ8zAfszL2Je1ZnG9sbLRCbGjQ0Tz/T/JsfXuZWOmL1Yv8jUd11agGLDkLjQuN8+eisOEXXWrNU= X-Received: by 2002:aca:cc8a:: with SMTP id c132mr3702512oig.173.1602276480536; Fri, 09 Oct 2020 13:48:00 -0700 (PDT) MIME-Version: 1.0 References: <20201009200737.GA78914@CptOrmolo.darkstar> In-Reply-To: From: Bart Schaefer Date: Fri, 9 Oct 2020 13:47:49 -0700 Message-ID: Subject: Re: [patch] Avoid race in zf_mkdir To: Roman Perepelitsa Cc: "zsh-workers@zsh.org" Content-Type: multipart/alternative; boundary="00000000000074653905b1431076" X-Seq: 47439 Archived-At: X-Loop: zsh-workers@zsh.org Errors-To: zsh-workers-owner@zsh.org Precedence: list Precedence: bulk Sender: zsh-workers-request@zsh.org X-no-archive: yes List-Id: List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: List-Archive: Archived-At: --00000000000074653905b1431076 Content-Type: text/plain; charset="UTF-8" On Fri, Oct 9, 2020 at 1:35 PM Roman Perepelitsa < roman.perepelitsa@gmail.com> wrote: > On Fri, Oct 9, 2020 at 10:25 PM Bart Schaefer > wrote: > > > > Er, sorry, this doesn't actually avoid the race, it just prevents the > error message from being shown by whichever shell loses the race. > > I think this is the expected behavior. It's prescribed by POSIX for mkdir. > [...] > > The patch is incorrect for a different reason. If `zf_mkdir -p foo` is > racing with another process that's doing `mkdir foo && rmdir foo`, the > zf_mkdir call must never fail but with this patch it can fail. > Hm ... in that case the code shouldn't call stat() unless the mkdir() gives EEXIST? And then ignore ENOENT from stat()? What if another process is doing "touch foo && rm foo"? How is it possible to distinguish that from mkdir+rmdir ? Or are we confusing the requirements for mkdir(2) from those for mkdir(1) ? I don't have the spec handy. --00000000000074653905b1431076 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Oct 9, 2020 at 1:35 PM Roman Pere= pelitsa <roman.perepelits= a@gmail.com> wrote:
On Fri, Oct 9, 2020 at 10:25 PM Bart = Schaefer <schaefer@brasslantern.com> wrote:
>
> Er, sorry, this doesn't actually avoid the race, it just prevents = the error message from being shown by whichever shell loses the race.

I think this is the expected behavior. It's prescribed by POSIX for mkd= ir.
[...]

The patch is incorrect for a different reason. If `zf_mkdir -p foo` is
racing with another process that's doing `mkdir foo && rmdir fo= o`, the
zf_mkdir call must never fail but with this patch it can fail.

Hm ... in that case the code shouldn't call sta= t() unless the mkdir() gives EEXIST?=C2=A0 And then ignore ENOENT from stat= ()?

What if another process is doing "touch f= oo && rm foo"?=C2=A0 How is it possible to distinguish that fr= om mkdir+rmdir ?

Or are we confusing the requ= irements for mkdir(2) from those for mkdir(1) ?=C2=A0 I don't have the = spec handy.
--00000000000074653905b1431076--