From unknown Fri Jun 20 07:28:15 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#41001 <41001@debbugs.gnu.org> To: bug#41001 <41001@debbugs.gnu.org> Subject: Status: mkdir: cannot create directory =?UTF-8?Q?=E2=80=98test=E2=80=99:?= File exists Reply-To: bug#41001 <41001@debbugs.gnu.org> Date: Fri, 20 Jun 2025 14:28:15 +0000 retitle 41001 mkdir: cannot create directory =E2=80=98test=E2=80=99: File e= xists reassign 41001 coreutils submitter 41001 Jonny Grant severity 41001 normal tag 41001 notabug thanks From debbugs-submit-bounces@debbugs.gnu.org Fri May 01 11:15:54 2020 Received: (at submit) by debbugs.gnu.org; 1 May 2020 15:15:54 +0000 Received: from localhost ([127.0.0.1]:50430 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jUXOI-0002Jc-Ld for submit@debbugs.gnu.org; Fri, 01 May 2020 11:15:54 -0400 Received: from lists.gnu.org ([209.51.188.17]:36450) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jUXOH-0002JV-3p for submit@debbugs.gnu.org; Fri, 01 May 2020 11:15:49 -0400 Received: from eggs.gnu.org ([209.51.188.92]:43176) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jUXNL-0007xH-NZ for bug-coreutils@gnu.org; Fri, 01 May 2020 11:15:48 -0400 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, T_SPF_PERMERROR,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.2 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jUXFR-0001bZ-PM for bug-coreutils@gnu.org; Fri, 01 May 2020 11:09:51 -0400 Received: from mail-wr1-x42d.google.com ([2a00:1450:4864:20::42d]:45680) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jUXFR-0001WI-3q for bug-coreutils@gnu.org; Fri, 01 May 2020 11:06:41 -0400 Received: by mail-wr1-x42d.google.com with SMTP id o27so6516681wra.12 for ; Fri, 01 May 2020 08:06:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jguk.org; s=google; h=to:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=8g+Kit+tMHvvdp0MKcxeTHfV3FFffFNLFVL2z5rwX30=; b=GudPPCafnoYwjUgeLcLOeDAy4xAA8XY+B/Yb9sAQ17bB3zd07oCfA0E9DPhctXndQv kl1ol5r0cV3U36GuKIwEO8YUdOXEnzlRYcqmGzbt9XwtaNgYrjl7eeqRqCsTVnp6urav rsYqbQEUOBfBlyXNOoA1gUMfAVk9d9MLfGNNWEeLgQ8QC/fYaHKl0nfWDYlB2ERb1zRa B5RKeSrImofALTHTIt2YvMXa3cVEQLXKuLgMsfQ3h0Gh7EYqIyHzpMVFopwzD94OrFuf EiBK9tgSimY1WffjOz3jUCHg/NlPYN+haasXXF0x9GaAKZRYFw9mYb53wDY6UJts8m5l NNJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=8g+Kit+tMHvvdp0MKcxeTHfV3FFffFNLFVL2z5rwX30=; b=YMFFCdirfzObCvUv+5TQYzy2YXKbYaQrB60yXf0T4rk9Qfm1dcKSVkaT0lMwRUQaT3 Oy6fEFemwMpOF3wE4r4CNs5eHPC+CkQWBUbEkEoFKznbtDyLfWNIRCVZJiO0tQ7HQR5d ITmEs/GjKT0nZz+EXiSz5ArED9++Y49jp29FegOfCssieQGcsS4qCi/NSm7eSZureG07 RcPtyKHXdlEC2CElY0uzCGWY6IDb920zDuf45ySzSBMgiRcVWMwO2B4VmVFIDJwrn1RV rm3Q959zZ0fPOETLdlgg3UPNT2gaKSv9w2AeP20si8tMNSnszIC1ZAPvAJgizav0ug4C TVwQ== X-Gm-Message-State: AGi0Pua8K42IFXpGNHuFbvNCS421pt/yF+/a0FcDVgEm+n6wzVFiAHfQ sUSxUpDb0y+hJHtx8Ydtz6Uwmw== X-Google-Smtp-Source: APiQypINDmG13IotT8Struco3H1QFwAwcQQJ+YyrXRQzwsiUWgH6yE1iSeil4vY7IAK+E76vv1xpQA== X-Received: by 2002:a5d:4843:: with SMTP id n3mr4500424wrs.7.1588345599067; Fri, 01 May 2020 08:06:39 -0700 (PDT) Received: from [192.168.0.12] (cpc87281-slou4-2-0-cust47.17-4.cable.virginm.net. [92.236.12.48]) by smtp.gmail.com with ESMTPSA id r5sm4724852wrt.20.2020.05.01.08.06.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 01 May 2020 08:06:38 -0700 (PDT) To: bug-coreutils@gnu.org From: Jonny Grant Subject: =?UTF-8?B?bWtkaXI6IGNhbm5vdCBjcmVhdGUgZGlyZWN0b3J5IOKAmHRlc3TigJk6?= =?UTF-8?Q?_File_exists?= Message-ID: <40df8619-2aec-9660-14f2-b674fc0e6d14@jguk.org> Date: Fri, 1 May 2020 16:06:36 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit Received-SPF: permerror client-ip=2a00:1450:4864:20::42d; envelope-from=jg@jguk.org; helo=mail-wr1-x42d.google.com X-detected-operating-system: by eggs.gnu.org: Error: [-] PROGRAM ABORT : Malformed IPv6 address (bad octet value). Location : parse_addr6(), p0f-client.c:67 X-Received-From: 2a00:1450:4864:20::42d X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Hello! Can this error message be clarified? The directory already exists, it is not a file. lib/mkdir-p.c:200 contains this line of code that triggers below:- error (0, mkdir_errno, _("cannot create directory %s"), quote (dir)); As it's easy enough to know that the reason mkdir fails is because 'test' a directory that already exists. Easy enough to check with stat() and S_ISDIR(sb.st_mode) Can this be changed? Maybe I can make a patch for it. Jonny $ mkdir test $ mkdir test mkdir: cannot create directory ‘test’: File exists $ mkdir --version mkdir (GNU coreutils) 8.28 Copyright (C) 2017 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later . This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Written by David MacKenzie. $ From debbugs-submit-bounces@debbugs.gnu.org Fri May 01 11:55:03 2020 Received: (at control) by debbugs.gnu.org; 1 May 2020 15:55:03 +0000 Received: from localhost ([127.0.0.1]:50486 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jUY0F-0003J9-1u for submit@debbugs.gnu.org; Fri, 01 May 2020 11:55:03 -0400 Received: from us-smtp-delivery-1.mimecast.com ([205.139.110.120]:40286 helo=us-smtp-1.mimecast.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jUY00-0003IN-FB for control@debbugs.gnu.org; Fri, 01 May 2020 11:54:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1588348488; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=lotni2sIq6vQT5an99X342oDL9/tytmJABq808iny10=; b=WMVHDIECglfwXw0cG+e352jjf4QPuVcfeHL0Xd5U33FE0wpe3aN8XqiEXWlxk9h1XMHXKO 4Ac62TXaZ/ryCZeH0o3U5uffK0wdwL+OY+98t4OnoJY3Bk6dYwP8ziURPowxM64tXQH34I phZie29d2P5N/XW+zeHYDSKcWDwVKFg= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-166-nkyjXuV7N6Gz6HDANJ2U9Q-1; Fri, 01 May 2020 11:54:42 -0400 X-MC-Unique: nkyjXuV7N6Gz6HDANJ2U9Q-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id CA3E88014C1; Fri, 1 May 2020 15:54:40 +0000 (UTC) Received: from [10.3.114.73] (ovpn-114-73.phx2.redhat.com [10.3.114.73]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 400675EDF1; Fri, 1 May 2020 15:54:40 +0000 (UTC) Subject: =?UTF-8?Q?Re=3a_bug=2341001=3a_mkdir=3a_cannot_create_directory_?= =?UTF-8?B?4oCYdGVzdOKAmTogRmlsZSBleGlzdHM=?= To: Jonny Grant , 41001-done@debbugs.gnu.org References: <40df8619-2aec-9660-14f2-b674fc0e6d14@jguk.org> From: Eric Blake Organization: Red Hat, Inc. Message-ID: <3e663b56-7771-20c6-45aa-c709a7ee7296@redhat.com> Date: Fri, 1 May 2020 10:54:37 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <40df8619-2aec-9660-14f2-b674fc0e6d14@jguk.org> Content-Language: en-US X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) tag 41001 notabug thanks On 5/1/20 10:06 AM, Jonny Grant wrote: > Hello! >=20 > Can this error message be clarified? The directory already exists, it is= =20 > not a file. By one definition, a directory _is_ a file, just with different=20 semantics (in the same way a block device, character device, symlink,=20 fifo, or socket can also be a file). It is not a regular file, but "a=20 file" is any entry stored in a directory, and as subdirectories are=20 stored in a directory, they count as files. >=20 > lib/mkdir-p.c:200 contains this line of code that triggers below:- >=20 > error (0, mkdir_errno, _("cannot create directory %s"), quote (dir)); The error message in question is coming from libc's strerror() function;=20 if you want a different error message for EEXIST, you'll have to=20 convince glibc to update their error string tables. It is not something=20 that coreutils directly controls. And while we could indeed output a=20 custom message instead of using strerror(), that would confuse people=20 who have grown used to the strerror() message. >=20 > As it's easy enough to know that the reason mkdir fails is because=20 > 'test' a directory that already exists. >=20 > Easy enough to check with stat() and S_ISDIR(sb.st_mode) >=20 > Can this be changed? Maybe I can make a patch for it. > Jonny >=20 >=20 >=20 > $ mkdir test > $ mkdir test > mkdir: cannot create directory =E2=80=98test=E2=80=99: File exists If nothing else, you may want to consider using 'mkdir -p test', which=20 specifically checks if the reason for an EEXIST failure is because the=20 directory already exists. Once you do that, you don't need to patch=20 coreutils. Thus, I'm closing this as not a bug; but feel free to respond further=20 with any more comments on the topic. --=20 Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org From debbugs-submit-bounces@debbugs.gnu.org Fri May 01 12:16:24 2020 Received: (at 41001-done) by debbugs.gnu.org; 1 May 2020 16:16:24 +0000 Received: from localhost ([127.0.0.1]:50500 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jUYKu-0005u7-6e for submit@debbugs.gnu.org; Fri, 01 May 2020 12:16:24 -0400 Received: from mail-wr1-f52.google.com ([209.85.221.52]:34317) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jUYKr-0005tt-U6 for 41001-done@debbugs.gnu.org; Fri, 01 May 2020 12:16:22 -0400 Received: by mail-wr1-f52.google.com with SMTP id j1so12087775wrt.1 for <41001-done@debbugs.gnu.org>; Fri, 01 May 2020 09:16:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jguk.org; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=Xkjdr789BilDQTm69s0Mf2rZ1pVVl7NBpPMWrZ0VcE0=; b=HdAadxxK/imIx7pWvFv5y1pso55bNy7UkjIKbgiSkskwELxnqv4NwsgPKBozORpbiS drq34C6HSm03M+MALvv5+gRZMYmi7Mf0F5rLOAv5ytzoMITjKnAH2xU1jOudNWiwW+/c UihUGRyQVh5iihxPiS59qrZ8A00bXYipVndOrMdvXlVekg3J9617c6XPG0oSRSdpIyrJ dotHBf7JjE2OAb9fV0KEsGOdeZAyuhUuWoI7ewE4U0RpYJD3rXaaLdvTB92+wh3eDsZQ hZ9f/l9JtGAFDVXCaheMs/rPV2YZL2xpYT36fdITbawJZRXCV2Sz6BIS+4OOJdiOjkyf hDcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Xkjdr789BilDQTm69s0Mf2rZ1pVVl7NBpPMWrZ0VcE0=; b=ZJ8+UCi9SK9tIcNDx7Xx4RI3WOw68ofE5DBlOTurgNlMIi/nB4US2HWjgQ0j6yOTnk HyrDK2OgXH0huEYSNvsnPQcZyAfD8yHFpZ6/QOj1w8AZy+Rh7MPrMOfBQnnr0dN+tpom 2OO7o63Y1pxAuNU+y6v+8it+qHHdT4jwOdaCTfpD+RPcBZnewfLAPjOUl3eWAJUSE0/u MIFwCKg/BGIo3qKETt/Ps3Gm79fLM6PxOkjXm+I21mkRwn8vnjT6/xQNwlBO+MpoLXVL 2DAOoLRR8x028rglKV+UO+EcGpfKvUorVXO1mrzjR2/HJPs9cJAf+ycOI/o4L7RdxBWV 9zBg== X-Gm-Message-State: AGi0Pub4syReW5M7JqRs539VWG/F75a1R0dgKqbeRWMYtpIhRIe+IPsT YKKAjNsbnTIi6cD+NgKAPfzVLNKrJ7I= X-Google-Smtp-Source: APiQypI8nhP2S3K7xsNqAAZskewMAcGw//eT1Udr3HNPIH9QMVI5ZEc7LLCBJnXzwSIOG9JUM7agFA== X-Received: by 2002:adf:df8d:: with SMTP id z13mr4902215wrl.304.1588349775596; Fri, 01 May 2020 09:16:15 -0700 (PDT) Received: from [192.168.0.12] (cpc87281-slou4-2-0-cust47.17-4.cable.virginm.net. [92.236.12.48]) by smtp.gmail.com with ESMTPSA id o3sm5013308wru.68.2020.05.01.09.16.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 01 May 2020 09:16:14 -0700 (PDT) Subject: =?UTF-8?Q?Re=3a_bug=2341001=3a_mkdir=3a_cannot_create_directory_?= =?UTF-8?B?4oCYdGVzdOKAmTogRmlsZSBleGlzdHM=?= To: Eric Blake , 41001-done@debbugs.gnu.org References: <40df8619-2aec-9660-14f2-b674fc0e6d14@jguk.org> <3e663b56-7771-20c6-45aa-c709a7ee7296@redhat.com> From: Jonny Grant Message-ID: <6f605632-0314-cb5d-d722-599d3e578e80@jguk.org> Date: Fri, 1 May 2020 17:16:13 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <3e663b56-7771-20c6-45aa-c709a7ee7296@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41001-done X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 01/05/2020 16:54, Eric Blake wrote: > tag 41001 notabug > thanks > > On 5/1/20 10:06 AM, Jonny Grant wrote: >> Hello! >> >> Can this error message be clarified? The directory already exists, it >> is not a file. > > By one definition, a directory _is_ a file, just with different > semantics (in the same way a block device, character device, symlink, > fifo, or socket can also be a file).  It is not a regular file, but "a > file" is any entry stored in a directory, and as subdirectories are > stored in a directory, they count as files. > >> >> lib/mkdir-p.c:200 contains this line of code that triggers below:- >> >> error (0, mkdir_errno, _("cannot create directory %s"), quote (dir)); > > The error message in question is coming from libc's strerror() function; > if you want a different error message for EEXIST, you'll have to > convince glibc to update their error string tables.  It is not something > that coreutils directly controls.  And while we could indeed output a > custom message instead of using strerror(), that would confuse people > who have grown used to the strerror() message. > >> >> As it's easy enough to know that the reason mkdir fails is because >> 'test' a directory that already exists. >> >> Easy enough to check with stat() and S_ISDIR(sb.st_mode) >> >> Can this be changed? Maybe I can make a patch for it. >> Jonny >> >> >> >> $ mkdir test >> $ mkdir test >> mkdir: cannot create directory ‘test’: File exists > > If nothing else, you may want to consider using 'mkdir -p test', which > specifically checks if the reason for an EEXIST failure is because the > directory already exists.  Once you do that, you don't need to patch > coreutils. > > Thus, I'm closing this as not a bug; but feel free to respond further > with any more comments on the topic. > Hello Eric! Yes, I can use mkdir -p as a workaround. Yes, I know everything is a file ultimately. However, most software does not call directories files as the routine behaviour for users. 'rm' and 'cat' are part of coreutils, that has output as I expected it. $ rm test rm: cannot remove 'test': Is a directory $ cat test cat: test: Is a directory I'm certain glibc won't/can't change EEXIST, as it is POSIX. $ strings test strings: Warning: 'test' is a directory $ vim test "test" is a directory on a tangent: I see the cat output doesn't put the name in quotes, perhaps it should? cat: 'test': Is a directory Regards Jonny From debbugs-submit-bounces@debbugs.gnu.org Fri May 01 14:07:58 2020 Received: (at 41001) by debbugs.gnu.org; 1 May 2020 18:07:58 +0000 Received: from localhost ([127.0.0.1]:50622 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jUa4r-0000La-S5 for submit@debbugs.gnu.org; Fri, 01 May 2020 14:07:58 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:49930) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jUa4p-0000LG-A1 for 41001@debbugs.gnu.org; Fri, 01 May 2020 14:07:56 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 6206A160079; Fri, 1 May 2020 11:07:49 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 2aND0Nqy6kVk; Fri, 1 May 2020 11:07:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id A8BBC160085; Fri, 1 May 2020 11:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 8mIDZblQDFuH; Fri, 1 May 2020 11:07:48 -0700 (PDT) Received: from [192.168.1.9] (cpe-23-242-74-103.socal.res.rr.com [23.242.74.103]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 78F6E160079; Fri, 1 May 2020 11:07:48 -0700 (PDT) Subject: =?UTF-8?Q?Re=3a_bug=2341001=3a_mkdir=3a_cannot_create_directory_?= =?UTF-8?B?4oCYdGVzdOKAmTogRmlsZSBleGlzdHM=?= To: Jonny Grant References: <40df8619-2aec-9660-14f2-b674fc0e6d14@jguk.org> <3e663b56-7771-20c6-45aa-c709a7ee7296@redhat.com> <6f605632-0314-cb5d-d722-599d3e578e80@jguk.org> From: Paul Eggert Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkV5QWNtUUJFQURB QXlIMnhvVHU3cHBHNUQzYThGTVpFb243NGRDdmM0K3ExWEEySjJ0QnkycHdhVHFmCmhweHhk R0E5Smo1MFVKM1BENGJTVUVnTjh0TFowc2FuNDdsNVhUQUZMaTI0NTZjaVNsNW04c0thSGxH ZHQ5WG0KQUF0bVhxZVpWSVlYL1VGUzk2ZkR6ZjR4aEVtbS95N0xiWUVQUWRVZHh1NDd4QTVL aFRZcDVibHRGM1dZRHoxWQpnZDdneDA3QXV3cDdpdzdlTnZub0RUQWxLQWw4S1lEWnpiRE5D UUdFYnBZM2VmWkl2UGRlSStGV1FONFcra2doCnkrUDZhdTZQcklJaFlyYWV1YTdYRGRiMkxT MWVuM1NzbUUzUWpxZlJxSS9BMnVlOEpNd3N2WGUvV0szOEV6czYKeDc0aVRhcUkzQUZINmls QWhEcXBNbmQvbXNTRVNORnQ3NkRpTzFaS1FNcjlhbVZQa25qZlBtSklTcWRoZ0IxRApsRWR3 MzRzUk9mNlY4bVp3MHhmcVQ2UEtFNDZMY0ZlZnpzMGtiZzRHT1JmOHZqRzJTZjF0azVlVThN Qml5Ti9iClowM2JLTmpOWU1wT0REUVF3dVA4NGtZTGtYMndCeHhNQWhCeHdiRFZadWR6eERa SjFDMlZYdWpDT0pWeHEya2wKakJNOUVUWXVVR3FkNzVBVzJMWHJMdzYrTXVJc0hGQVlBZ1Jy NytLY3dEZ0JBZndoUEJZWDM0blNTaUhsbUxDKwpLYUhMZUNMRjVaSTJ2S20zSEVlQ1R0bE9n N3haRU9OZ3d6TCtmZEtvK0Q2U29DOFJSeEpLczhhM3NWZkk0dDZDCm5yUXp2SmJCbjZneGRn Q3U1aTI5SjFRQ1lyQ1l2cWwyVXlGUEFLK2RvOTkvMWpPWFQ0bTI4MzZqMXdBUkFRQUIKdENC UVlYVnNJRVZuWjJWeWRDQThaV2RuWlhKMFFHTnpMblZqYkdFdVpXUjFQb2tDUGdRVEFRSUFL QVVDVElCeQpaQUliQXdVSkVzd0RBQVlMQ1FnSEF3SUdGUWdDQ1FvTEJCWUNBd0VDSGdFQ0Y0 QUFDZ2tRN1pmcERtS3FmalJSCkd3LytJajAzZGhZZllsL2dYVlJpdXpWMWdHcmJIayt0bmZy SS9DN2ZBZW9GelE1dFZnVmluU2hhUGtabzBIVFAKZjE4eDZJREVkQWlPOE1xbzF5cDBDdEht ekdNQ0o1MG80R3JnZmpscjZnLyt2dEVPS2JobGVzek4yWHBKdnB3TQoyUWdHdm4vbGFUTFV1 OFBIOWFSV1RzN3FKSlpLS0tBYjRzeFljOTJGZWhQdTZGT0QwZERpeWhsREFxNGxPVjJtCmRC cHpRYmlvam9aelFMTVF3anBnQ1RLMjU3MmVLOUVPRVF5U1VUaFhyU0l6NkFTZW5wNE5ZVEZI czl0dUpRdlgKazlnWkRkUFNsM2JwKzQ3ZEd4bHhFV0xwQklNN3pJT053NGtzNGF6Z1Q4bnZE WnhBNUlaSHR2cUJsSkxCT2JZWQowTGU2MVdwMHkzVGxCRGgycWRLOGVZTDQyNlc0c2NFTVN1 aWc1Z2I4T0F0UWlCVzZrMnNHVXh4ZWl2OG92V3U4CllBWmdLSmZ1b1dJK3VSbk1FZGRydVk4 SnNvTTU0S2FLdlppa2tLczJiZzFuZHRMVnpIcEo2cUZaQzdRVmplSFUKaDYvQm1ndmRqV1Ba WUZUdE4rS0E5Q1dYM0dRS0tnTjN1dTk4OHl6bkQ3TG5COThUNEVVSDFIQS9HbmZCcU1WMQpn cHpUdlBjNHFWUWluQ21Ja0VGcDgzemwrRzVmQ2pKSjNXN2l2ekNuWW80S2hLTHBGVW05N29r VEtSMkxXM3haCnpFVzRjTFNXTzM4N01USzNDekRPeDVxZTZzNGE5MVp1Wk0vai9UUWRUTERh cU5uODNrQTRIcTQ4VUhYWXhjSWgKK05kOGsvM3c2bEZ1b0swd3JPRml5d2pMeCswdXI1am1t YmVjQkdIYzF4ZGhBRkc1QWcwRVRJQnlaQUVRQUthRgo2NzhUOXd5SDR3alRyVjFQejNjREVv U25WLzBaVXJPVDM3cDFkY0d5ai9JWHExeDY3MEhSVmFoQW1rMHNacFljCjI1UEY5RDVHUFlI RldsTmp1UFU5NnJEbmRYQjNoZWRtQlJoTGRDNGJBWGpJNERWK2JtZFZlK3EvSU1ubFpSYVYK bG05RWlNQ1ZBUjZ3MTNzUmV1N3FYa1c5cjNSd1kyQXpYc2twL3RBZTRCUktyMVptYnZpMm5i blE2ZXBFQzQycgpSYngwQjFFaGpiSVFaNUpIR2syNGlQVDdMZEJnbk5tb3M1d1lqendObGtN UUQ1VDBZZHpoazdKK1V4d0E1bTQ2Cm1PaFJEQzJyRlYvQTBnbTVUTHk4RFhqdi9Fc2M0Z1lu WWFpNlNRcW5VRVZoNUx1VjhZQ0pCbmlqcytUaXc3MXgKMWljbW42eEdJNDVFdWdKT2dlYyty THlwWWdwVnA0eDBISTVUODhxQlJZQ2t4SDNLZzhRbytFV05BOUE0TFJROQpEWDhuam9uYTBn ZjBzMDN0b2NLOGtCTjY2VW9xcVB0SEJuYzRlTWdCeW1DZmxLMTJlS2ZkMllZeG55ZzljWmF6 CldBNVZzbHZUeHBtNzZoYmc1b2lBRUgvVmcvOE14SHlBblBoZnJnd3lQcm1KRWNWQmFmZHNw Sm5ZUXhCWU5jbzIKTEZQSWhsT3ZXaDhyNGF0K3MrTTNMYjI2b1VUY3psZ2RXMVNmM1NEQTc3 Qk1SbkYwRlF5RSs3QXpWNzlNQk40eQpraXFhZXpReHRhRjFGeS90dmtoZmZTbzh1K2R3RzBF Z0poK3RlMzhnVGNJU1ZyMEdJUHBsTHo2WWhqcmJIclBSCkYxQ041VXVMOURCR2p4dU4zNVJM TlZFZnRhNlJVRmxSNk5jdFRqdnJBQkVCQUFHSkFpVUVHQUVDQUE4RkFreUEKY21RQ0d3d0ZD UkxNQXdBQUNna1E3WmZwRG1LcWZqU3JIQS8rS3pBS3ZUeFJoQTlNV05MeEl5SjdTNXVKMTZn cwpUM29DalpyQktHRWhLTU9HWDRPMEdBNlZPRXJ5TzdRUkNDWWFoM294U0czOElBbk5laXdK WGdVOUJ6a2s4NVVHCmJQRWQ3SEdGL1ZTZUhDUXdXb3U2anFVRFRTRHZuOVloTlRkRzBLWFBN NzRhQyt4cjJab3cxTzJtaFhpaGdXS0QKMER3KzBMWVBuVU9zUTBLT0Z4SFhYWUhtUnJTMU9a UFU1OUJMdmMrVFJoSWhhZlNIS0x3YlhLKzZja2t4Qng2aAo4ejVjY3BHMFFzNGJGaGRGWW5G ckVpZURMb0dtbkUyWUxoZFY2c3dKOVZOQ1M2cExpRW9oVDNmbTdhWG0xNXRaCk9JeXpNWmhI UlNBUGJsWHhRMFpTV2pxOG9ScmNZTkZ4YzRXMVVScEFrQkNPWUpvWHZRZkQ1TDNscUFsOFRD cUQKVXpZeGhIL3RKaGJEZEhycUhINzY3amFEYVRCMStUYWxwLzJBTUt3Y1hOT2Rpa2xHeGJt SFZHNllHbDZnOExyYgpzdTlOWkVJNHlMbEh6dWlrdGhKV2d6KzN2WmhWR3lObHQrSE5Jb0Y2 Q2pETDJvbXU1Y0VxNFJESE00NFFxUGs2Cmw3TzBwVXZOMW1UNEIrUzFiMDhSS3BxbS9mZjAx NUUzN0hOVi9waUl2Smx4R0FZejhQU2Z1R0NCMXRoTVlxbG0KZ2RoZDkvQmFiR0ZiR0dZSEE2 VTQvVDV6cVUrZjZ4SHkxU3NBUVoxTVNLbEx3ZWtCSVQrNC9jTFJHcUNIam5WMApxNUgvVDZh N3Q1bVBrYnpTck9MU280cHVqK0lUb05qWXlZSURCV3pobEExOWF2T2ErcnZVam1IdEQzc0ZO N2NYCld0a0dvaThidU5jYnk0VT0KPUFMNm8KLS0tLS1FTkQgUEdQIFBVQkxJQyBLRVkgQkxP Q0stLS0tLQo= Organization: UCLA Computer Science Department Message-ID: <232f6665-7edd-842c-ac9d-4fd2d6d86368@cs.ucla.edu> Date: Fri, 1 May 2020 11:07:48 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <6f605632-0314-cb5d-d722-599d3e578e80@jguk.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 41001 Cc: 41001@debbugs.gnu.org, Eric Blake X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 5/1/20 9:16 AM, Jonny Grant wrote: > rm: cannot remove 'test': Is a directory That's because rm used unlink which failed with EISDIR, which is a differ= ent error number. Consider this example: $ >d # Create an empty regular file. $ mkdir d mkdir: cannot create directory =E2=80=98d=E2=80=99: File exists Here the system call mkdir("d", 0777) failed with errno =3D=3D EEXIST (Fi= le exists). Presumably you wouldn't object to the diagnostic here because d is a regu= lar file, not a directory. But the mkdir system call fails in exactly the sam= e way if d is a directory, so the error message is the same in both cases. Directories are files, so the error message is correct even if it confuse= d you. I don't see any portable and efficient way to make the diagnostic less co= nfusing for you, without also making diagnostic incorrect in some other scenarios= (such as the scenario described above). From debbugs-submit-bounces@debbugs.gnu.org Fri May 01 16:21:56 2020 Received: (at 41001) by debbugs.gnu.org; 1 May 2020 20:21:56 +0000 Received: from localhost ([127.0.0.1]:50739 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jUcAV-0005qi-Us for submit@debbugs.gnu.org; Fri, 01 May 2020 16:21:56 -0400 Received: from mail-wm1-f68.google.com ([209.85.128.68]:37658) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jUcAR-0005qS-1O for 41001@debbugs.gnu.org; Fri, 01 May 2020 16:21:55 -0400 Received: by mail-wm1-f68.google.com with SMTP id z6so941074wml.2 for <41001@debbugs.gnu.org>; Fri, 01 May 2020 13:21:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jguk.org; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=ZC5rsXzkg7CvKYSOHVjGyJxJ8rI62K0D1d5IRH+a98Q=; b=oFykbkZyeFP2kOzMOFrKr8aQCcpxtto5HclVRG61r2lyHrWZaC/4ingA3Twni8Eoj6 j/jp+L+SP0FNeZmZzpTJiiCUPmgh2CJ8i3GNl288QlgyyRk5mYCwJ1irGzT8pC1QgIhL 8Mh76KyDEUJAJwsktIhDtgoiaU20vibLgF++SnSODJCRjjmt6vCm4TU2cSrRPN351aAe b5aUnY8Cu82PhxAzoPkrPf1IomzYFScNAh6IAQHGXX8BfNhXmF+OiT84tHdOX+46i4eb yudoGN2daVGTeBWyfVotKVT5KV1OgLLqVjshvGDJvkuUMyjHX9hSULkP9ZNzdMj4EGMc Y24A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ZC5rsXzkg7CvKYSOHVjGyJxJ8rI62K0D1d5IRH+a98Q=; b=UBOJM3HO8K11OLcIxrJUj5P60bkvEepMr3i+CS4RVqm2yU53JGzRrcyJ6CfZ/2Z4UK 8NNZNIs+euFDtIVHiJrPjzjOcUyIOLM9RkAiQXHCwazs7QQac2VUk+HYefqQ2lmHiRQ7 MF4EWx4FIxiTJRzgSBOzMtPy9vsz6PbwrkF2itDCVolXc3lJey0fuIkqDK/5pAZHQKWz q+3EYH75tP6TqzkJgT5yvsC+pE4goIJ3XdqAweJBtev6qCTnH2Go1/roFAswr/spCjB6 UctEWlAFBmqzrR7xLGXkQMUF1eKkhMGatg+q/z+vOYAdLNuKfe0NGaqbrYDtVvdp6RwX i7pw== X-Gm-Message-State: AGi0PuY7BvyBzsR2d+gHoEo1ye4s/HJQYUsITHlk08BroaQfVrh2h/aP Ws950Reh2JUs7nisahAtjE3J9Ldyi0o= X-Google-Smtp-Source: APiQypJ0SK0yUAeMKk0QgBcEIYBYPGz6NWE7a4IV6SL6mHXRHklg6odwLiJz8mFicH7bbhegdlfufg== X-Received: by 2002:a1c:9989:: with SMTP id b131mr1178813wme.176.1588364504782; Fri, 01 May 2020 13:21:44 -0700 (PDT) Received: from [192.168.0.12] (cpc87281-slou4-2-0-cust47.17-4.cable.virginm.net. [92.236.12.48]) by smtp.gmail.com with ESMTPSA id w10sm6058120wrg.52.2020.05.01.13.21.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 01 May 2020 13:21:44 -0700 (PDT) Subject: =?UTF-8?Q?Re=3a_bug=2341001=3a_mkdir=3a_cannot_create_directory_?= =?UTF-8?B?4oCYdGVzdOKAmTogRmlsZSBleGlzdHM=?= To: Paul Eggert References: <40df8619-2aec-9660-14f2-b674fc0e6d14@jguk.org> <3e663b56-7771-20c6-45aa-c709a7ee7296@redhat.com> <6f605632-0314-cb5d-d722-599d3e578e80@jguk.org> <232f6665-7edd-842c-ac9d-4fd2d6d86368@cs.ucla.edu> From: Jonny Grant Message-ID: Date: Fri, 1 May 2020 21:21:42 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <232f6665-7edd-842c-ac9d-4fd2d6d86368@cs.ucla.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41001 Cc: 41001@debbugs.gnu.org, Eric Blake X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 01/05/2020 19:07, Paul Eggert wrote: > On 5/1/20 9:16 AM, Jonny Grant wrote: >> rm: cannot remove 'test': Is a directory > > That's because rm used unlink which failed with EISDIR, which is a different > error number. yes, the fix pretty trivial for mkdir as you highlight EISDIR: stat(), S_ISDIR(sb.st_mode), and set errno to EISDIR or output strerror(EISDIR) $ mkdir test mkdir: cannot create directory ‘test’: Is a directory > Consider this example: > > $ >d # Create an empty regular file. > $ mkdir d > mkdir: cannot create directory ‘d’: File exists > > Here the system call mkdir("d", 0777) failed with errno == EEXIST (File exists). > Presumably you wouldn't object to the diagnostic here because d is a regular > file, not a directory. But the mkdir system call fails in exactly the same way > if d is a directory, so the error message is the same in both cases. Exactly, UNIX didn't create separate errno for files and directories, it's the same limitation with ENOENT. As a developer, we handle it ourselves, as it's easy enough to call stat() like other package maintainers do, as you can see in binutils. > Directories are files, so the error message is correct even if it confused you. > I don't see any portable and efficient way to make the diagnostic less confusing > for you, without also making diagnostic incorrect in some other scenarios (such > as the scenario described above). Feels like the fix I already proposed does not have any incorrect impact in the other scenario you describe? Do correct me if I am missing something. Yes, as a developer I know everything is actually a file, but users don't. Users will call it a folder, or a directory. I didn't go over UNIX everything-is-a-file in my bug report because everyone here knows already. This one is an simple fix, but it's clear no one wants to introduce the change, no worries. Cheers, Jonny From debbugs-submit-bounces@debbugs.gnu.org Fri May 01 16:32:29 2020 Received: (at 41001) by debbugs.gnu.org; 1 May 2020 20:32:29 +0000 Received: from localhost ([127.0.0.1]:50755 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jUcKj-0006AW-13 for submit@debbugs.gnu.org; Fri, 01 May 2020 16:32:29 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:51534) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jUcKg-0006AC-SI for 41001@debbugs.gnu.org; Fri, 01 May 2020 16:32:27 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id A524F160066; Fri, 1 May 2020 13:32:20 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id yMOA77Z8DHVu; Fri, 1 May 2020 13:32:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 0064A1600C7; Fri, 1 May 2020 13:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id DgohjhwepcJC; Fri, 1 May 2020 13:32:19 -0700 (PDT) Received: from [192.168.1.9] (cpe-23-242-74-103.socal.res.rr.com [23.242.74.103]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id BB9D7160066; Fri, 1 May 2020 13:32:19 -0700 (PDT) Subject: =?UTF-8?Q?Re=3a_bug=2341001=3a_mkdir=3a_cannot_create_directory_?= =?UTF-8?B?4oCYdGVzdOKAmTogRmlsZSBleGlzdHM=?= To: Jonny Grant References: <40df8619-2aec-9660-14f2-b674fc0e6d14@jguk.org> <3e663b56-7771-20c6-45aa-c709a7ee7296@redhat.com> <6f605632-0314-cb5d-d722-599d3e578e80@jguk.org> <232f6665-7edd-842c-ac9d-4fd2d6d86368@cs.ucla.edu> From: Paul Eggert Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkV5QWNtUUJFQURB QXlIMnhvVHU3cHBHNUQzYThGTVpFb243NGRDdmM0K3ExWEEySjJ0QnkycHdhVHFmCmhweHhk R0E5Smo1MFVKM1BENGJTVUVnTjh0TFowc2FuNDdsNVhUQUZMaTI0NTZjaVNsNW04c0thSGxH ZHQ5WG0KQUF0bVhxZVpWSVlYL1VGUzk2ZkR6ZjR4aEVtbS95N0xiWUVQUWRVZHh1NDd4QTVL aFRZcDVibHRGM1dZRHoxWQpnZDdneDA3QXV3cDdpdzdlTnZub0RUQWxLQWw4S1lEWnpiRE5D UUdFYnBZM2VmWkl2UGRlSStGV1FONFcra2doCnkrUDZhdTZQcklJaFlyYWV1YTdYRGRiMkxT MWVuM1NzbUUzUWpxZlJxSS9BMnVlOEpNd3N2WGUvV0szOEV6czYKeDc0aVRhcUkzQUZINmls QWhEcXBNbmQvbXNTRVNORnQ3NkRpTzFaS1FNcjlhbVZQa25qZlBtSklTcWRoZ0IxRApsRWR3 MzRzUk9mNlY4bVp3MHhmcVQ2UEtFNDZMY0ZlZnpzMGtiZzRHT1JmOHZqRzJTZjF0azVlVThN Qml5Ti9iClowM2JLTmpOWU1wT0REUVF3dVA4NGtZTGtYMndCeHhNQWhCeHdiRFZadWR6eERa SjFDMlZYdWpDT0pWeHEya2wKakJNOUVUWXVVR3FkNzVBVzJMWHJMdzYrTXVJc0hGQVlBZ1Jy NytLY3dEZ0JBZndoUEJZWDM0blNTaUhsbUxDKwpLYUhMZUNMRjVaSTJ2S20zSEVlQ1R0bE9n N3haRU9OZ3d6TCtmZEtvK0Q2U29DOFJSeEpLczhhM3NWZkk0dDZDCm5yUXp2SmJCbjZneGRn Q3U1aTI5SjFRQ1lyQ1l2cWwyVXlGUEFLK2RvOTkvMWpPWFQ0bTI4MzZqMXdBUkFRQUIKdENC UVlYVnNJRVZuWjJWeWRDQThaV2RuWlhKMFFHTnpMblZqYkdFdVpXUjFQb2tDUGdRVEFRSUFL QVVDVElCeQpaQUliQXdVSkVzd0RBQVlMQ1FnSEF3SUdGUWdDQ1FvTEJCWUNBd0VDSGdFQ0Y0 QUFDZ2tRN1pmcERtS3FmalJSCkd3LytJajAzZGhZZllsL2dYVlJpdXpWMWdHcmJIayt0bmZy SS9DN2ZBZW9GelE1dFZnVmluU2hhUGtabzBIVFAKZjE4eDZJREVkQWlPOE1xbzF5cDBDdEht ekdNQ0o1MG80R3JnZmpscjZnLyt2dEVPS2JobGVzek4yWHBKdnB3TQoyUWdHdm4vbGFUTFV1 OFBIOWFSV1RzN3FKSlpLS0tBYjRzeFljOTJGZWhQdTZGT0QwZERpeWhsREFxNGxPVjJtCmRC cHpRYmlvam9aelFMTVF3anBnQ1RLMjU3MmVLOUVPRVF5U1VUaFhyU0l6NkFTZW5wNE5ZVEZI czl0dUpRdlgKazlnWkRkUFNsM2JwKzQ3ZEd4bHhFV0xwQklNN3pJT053NGtzNGF6Z1Q4bnZE WnhBNUlaSHR2cUJsSkxCT2JZWQowTGU2MVdwMHkzVGxCRGgycWRLOGVZTDQyNlc0c2NFTVN1 aWc1Z2I4T0F0UWlCVzZrMnNHVXh4ZWl2OG92V3U4CllBWmdLSmZ1b1dJK3VSbk1FZGRydVk4 SnNvTTU0S2FLdlppa2tLczJiZzFuZHRMVnpIcEo2cUZaQzdRVmplSFUKaDYvQm1ndmRqV1Ba WUZUdE4rS0E5Q1dYM0dRS0tnTjN1dTk4OHl6bkQ3TG5COThUNEVVSDFIQS9HbmZCcU1WMQpn cHpUdlBjNHFWUWluQ21Ja0VGcDgzemwrRzVmQ2pKSjNXN2l2ekNuWW80S2hLTHBGVW05N29r VEtSMkxXM3haCnpFVzRjTFNXTzM4N01USzNDekRPeDVxZTZzNGE5MVp1Wk0vai9UUWRUTERh cU5uODNrQTRIcTQ4VUhYWXhjSWgKK05kOGsvM3c2bEZ1b0swd3JPRml5d2pMeCswdXI1am1t YmVjQkdIYzF4ZGhBRkc1QWcwRVRJQnlaQUVRQUthRgo2NzhUOXd5SDR3alRyVjFQejNjREVv U25WLzBaVXJPVDM3cDFkY0d5ai9JWHExeDY3MEhSVmFoQW1rMHNacFljCjI1UEY5RDVHUFlI RldsTmp1UFU5NnJEbmRYQjNoZWRtQlJoTGRDNGJBWGpJNERWK2JtZFZlK3EvSU1ubFpSYVYK bG05RWlNQ1ZBUjZ3MTNzUmV1N3FYa1c5cjNSd1kyQXpYc2twL3RBZTRCUktyMVptYnZpMm5i blE2ZXBFQzQycgpSYngwQjFFaGpiSVFaNUpIR2syNGlQVDdMZEJnbk5tb3M1d1lqendObGtN UUQ1VDBZZHpoazdKK1V4d0E1bTQ2Cm1PaFJEQzJyRlYvQTBnbTVUTHk4RFhqdi9Fc2M0Z1lu WWFpNlNRcW5VRVZoNUx1VjhZQ0pCbmlqcytUaXc3MXgKMWljbW42eEdJNDVFdWdKT2dlYyty THlwWWdwVnA0eDBISTVUODhxQlJZQ2t4SDNLZzhRbytFV05BOUE0TFJROQpEWDhuam9uYTBn ZjBzMDN0b2NLOGtCTjY2VW9xcVB0SEJuYzRlTWdCeW1DZmxLMTJlS2ZkMllZeG55ZzljWmF6 CldBNVZzbHZUeHBtNzZoYmc1b2lBRUgvVmcvOE14SHlBblBoZnJnd3lQcm1KRWNWQmFmZHNw Sm5ZUXhCWU5jbzIKTEZQSWhsT3ZXaDhyNGF0K3MrTTNMYjI2b1VUY3psZ2RXMVNmM1NEQTc3 Qk1SbkYwRlF5RSs3QXpWNzlNQk40eQpraXFhZXpReHRhRjFGeS90dmtoZmZTbzh1K2R3RzBF Z0poK3RlMzhnVGNJU1ZyMEdJUHBsTHo2WWhqcmJIclBSCkYxQ041VXVMOURCR2p4dU4zNVJM TlZFZnRhNlJVRmxSNk5jdFRqdnJBQkVCQUFHSkFpVUVHQUVDQUE4RkFreUEKY21RQ0d3d0ZD UkxNQXdBQUNna1E3WmZwRG1LcWZqU3JIQS8rS3pBS3ZUeFJoQTlNV05MeEl5SjdTNXVKMTZn cwpUM29DalpyQktHRWhLTU9HWDRPMEdBNlZPRXJ5TzdRUkNDWWFoM294U0czOElBbk5laXdK WGdVOUJ6a2s4NVVHCmJQRWQ3SEdGL1ZTZUhDUXdXb3U2anFVRFRTRHZuOVloTlRkRzBLWFBN NzRhQyt4cjJab3cxTzJtaFhpaGdXS0QKMER3KzBMWVBuVU9zUTBLT0Z4SFhYWUhtUnJTMU9a UFU1OUJMdmMrVFJoSWhhZlNIS0x3YlhLKzZja2t4Qng2aAo4ejVjY3BHMFFzNGJGaGRGWW5G ckVpZURMb0dtbkUyWUxoZFY2c3dKOVZOQ1M2cExpRW9oVDNmbTdhWG0xNXRaCk9JeXpNWmhI UlNBUGJsWHhRMFpTV2pxOG9ScmNZTkZ4YzRXMVVScEFrQkNPWUpvWHZRZkQ1TDNscUFsOFRD cUQKVXpZeGhIL3RKaGJEZEhycUhINzY3amFEYVRCMStUYWxwLzJBTUt3Y1hOT2Rpa2xHeGJt SFZHNllHbDZnOExyYgpzdTlOWkVJNHlMbEh6dWlrdGhKV2d6KzN2WmhWR3lObHQrSE5Jb0Y2 Q2pETDJvbXU1Y0VxNFJESE00NFFxUGs2Cmw3TzBwVXZOMW1UNEIrUzFiMDhSS3BxbS9mZjAx NUUzN0hOVi9waUl2Smx4R0FZejhQU2Z1R0NCMXRoTVlxbG0KZ2RoZDkvQmFiR0ZiR0dZSEE2 VTQvVDV6cVUrZjZ4SHkxU3NBUVoxTVNLbEx3ZWtCSVQrNC9jTFJHcUNIam5WMApxNUgvVDZh N3Q1bVBrYnpTck9MU280cHVqK0lUb05qWXlZSURCV3pobEExOWF2T2ErcnZVam1IdEQzc0ZO N2NYCld0a0dvaThidU5jYnk0VT0KPUFMNm8KLS0tLS1FTkQgUEdQIFBVQkxJQyBLRVkgQkxP Q0stLS0tLQo= Organization: UCLA Computer Science Department Message-ID: <48d4fbd5-3e57-00b3-9a3e-3f0795fa743f@cs.ucla.edu> Date: Fri, 1 May 2020 13:32:19 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 41001 Cc: 41001@debbugs.gnu.org, Eric Blake X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 5/1/20 1:21 PM, Jonny Grant wrote: > yes, the fix pretty trivial for mkdir as you highlight EISDIR: > stat(), S_ISDIR(sb.st_mode), and set errno to EISDIR or output strerror(EISDIR) That would introduce a race condition, and wouldn't behave correctly if some other process changes the destination from a regular file to a directory between the time we call mkdir and the time that we call stat. From debbugs-submit-bounces@debbugs.gnu.org Sat May 02 09:26:46 2020 Received: (at 41001) by debbugs.gnu.org; 2 May 2020 13:26:46 +0000 Received: from localhost ([127.0.0.1]:51568 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jUsAI-0002ZN-1E for submit@debbugs.gnu.org; Sat, 02 May 2020 09:26:46 -0400 Received: from mail-wm1-f65.google.com ([209.85.128.65]:39445) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jUsAF-0002Z9-Hi for 41001@debbugs.gnu.org; Sat, 02 May 2020 09:26:44 -0400 Received: by mail-wm1-f65.google.com with SMTP id y24so3288435wma.4 for <41001@debbugs.gnu.org>; Sat, 02 May 2020 06:26:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jguk.org; s=google; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=WdwZkGkfwjSXkgcE+LeTU52uuBMrNVh9wVBvO8ADrus=; b=P6llQzKFWaEFfTOdXFaOVDZwZ5Uy39izIRZ8xw7kTzfG3LNspTecLwJxu9I35OR1Lj PfkCemXbe5VBNTCa1Jv9d6IwSULGgxp1bCQ8iirV5nKBM1VJ6LSrmxwY3+MvRMN/NLnT kLmDV/ZW5X9YQRDtRv7FoArL0S0F7gqCmVwFJ5Tgp1LoL6/D+KltGcAV1VPXrjYL0j9i XvCI7qfxKrHpmByxyL3VEvfxdq4xQ+RqSQFabcf13ZFXuttYjYJQWibjCMWGNbkiHXx/ VAvfEtzx0cj3zW1i2knfpnvf0DOM0cR31r0RZ+PbIK4vdt3rj4Du9+tWp1cK4okvmv8S 2AoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=WdwZkGkfwjSXkgcE+LeTU52uuBMrNVh9wVBvO8ADrus=; b=foA1PdO7tSD/7MIEronRy1fPzIXd8l5jGQEJGlHpRN2djTaV86X1ryALyMiLp7pLkE F416OgccV7xrnoV/SUojSg2ZiLgqWUd3G7pGYkZJpG+Vnw+GIm/b0efn7JLfspOwZ2O7 hXKQZpXGylZbeatOw12aq+/cCnVuDXv0bB31ietwWeDRMpL7Jff0EqabvWnajIDGJ/oy fpdVMhdRTxoNcxzNLAobPMvJpwfRN6iMnIA1lr1rVD98jjKwB7reH4695rjzTeUx7Arv xv3vX3f/UZo0vmIsAOMrnK7pJ9WBe1uC9nUFwKiKJy36Na21auKKqtd0IgPC8Dbo8keZ CKgw== X-Gm-Message-State: AGi0PubkwgHraCHhSPgkXAqa6sKNe+QIZvCBu+WS3fK3dNuLqJajz/Jv BtpgCgwaHI+urt2scYFi0PaabM1JM5o= X-Google-Smtp-Source: APiQypJRLXYkmWPcRCoqB7WAL3sJQG0wPdIg+9CO4rtffglUn2dz9CgopEAoeSWpg9g8NZIgq0ZUEA== X-Received: by 2002:a7b:ce09:: with SMTP id m9mr4539439wmc.156.1588425997072; Sat, 02 May 2020 06:26:37 -0700 (PDT) Received: from [192.168.0.12] (cpc87281-slou4-2-0-cust47.17-4.cable.virginm.net. [92.236.12.48]) by smtp.gmail.com with ESMTPSA id z11sm1049874wro.48.2020.05.02.06.26.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 02 May 2020 06:26:36 -0700 (PDT) From: Jonny Grant Subject: =?UTF-8?Q?Re=3a_bug=2341001=3a_mkdir=3a_cannot_create_directory_?= =?UTF-8?B?4oCYdGVzdOKAmTogRmlsZSBleGlzdHM=?= To: Paul Eggert References: <40df8619-2aec-9660-14f2-b674fc0e6d14@jguk.org> <3e663b56-7771-20c6-45aa-c709a7ee7296@redhat.com> <6f605632-0314-cb5d-d722-599d3e578e80@jguk.org> <232f6665-7edd-842c-ac9d-4fd2d6d86368@cs.ucla.edu> <48d4fbd5-3e57-00b3-9a3e-3f0795fa743f@cs.ucla.edu> Message-ID: <72ead2e2-85e5-723f-ecc8-63bf7d610c57@jguk.org> Date: Sat, 2 May 2020 14:26:35 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <48d4fbd5-3e57-00b3-9a3e-3f0795fa743f@cs.ucla.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41001 Cc: 41001@debbugs.gnu.org, Eric Blake X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 01/05/2020 21:32, Paul Eggert wrote: > On 5/1/20 1:21 PM, Jonny Grant wrote: >> yes, the fix pretty trivial for mkdir as you highlight EISDIR: >> stat(), S_ISDIR(sb.st_mode), and set errno to EISDIR or output strerror(EISDIR) > > That would introduce a race condition, and wouldn't behave correctly if some > other process changes the destination from a regular file to a directory between > the time we call mkdir and the time that we call stat. Paul, If developers have race conditions in their shell scripts - mkdir error string in the message after the colon in the output saying file/directory is the least of the developers' problems. mkdir() returning EEXIST only indicates the pathname exists. Maybe call stat() before calling mkdir() to check nothing there. It's more a question of doing something appropriate. Personally I doubt POSIX will ever be updated to have more errno errors that distinguish between files and directories for ENOENT and EEXIST due to people's fears about compatibility when APIs are updated. Cheers, Jonny From debbugs-submit-bounces@debbugs.gnu.org Sat May 02 15:48:12 2020 Received: (at 41001) by debbugs.gnu.org; 2 May 2020 19:48:12 +0000 Received: from localhost ([127.0.0.1]:53969 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jUy7D-0002So-8i for submit@debbugs.gnu.org; Sat, 02 May 2020 15:48:12 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:57868) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jUy7B-0002Sa-DO for 41001@debbugs.gnu.org; Sat, 02 May 2020 15:47:58 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 3FB3C1600E1; Sat, 2 May 2020 12:47:51 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 2XGcsgz2sLhT; Sat, 2 May 2020 12:47:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 5CACB1600E4; Sat, 2 May 2020 12:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id riECSU_CWQ5u; Sat, 2 May 2020 12:47:50 -0700 (PDT) Received: from [192.168.1.9] (cpe-23-242-74-103.socal.res.rr.com [23.242.74.103]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 14AEA1600E1; Sat, 2 May 2020 12:47:50 -0700 (PDT) Subject: =?UTF-8?Q?Re=3a_bug=2341001=3a_mkdir=3a_cannot_create_directory_?= =?UTF-8?B?4oCYdGVzdOKAmTogRmlsZSBleGlzdHM=?= To: Jonny Grant References: <40df8619-2aec-9660-14f2-b674fc0e6d14@jguk.org> <3e663b56-7771-20c6-45aa-c709a7ee7296@redhat.com> <6f605632-0314-cb5d-d722-599d3e578e80@jguk.org> <232f6665-7edd-842c-ac9d-4fd2d6d86368@cs.ucla.edu> <48d4fbd5-3e57-00b3-9a3e-3f0795fa743f@cs.ucla.edu> <72ead2e2-85e5-723f-ecc8-63bf7d610c57@jguk.org> From: Paul Eggert Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkV5QWNtUUJFQURB QXlIMnhvVHU3cHBHNUQzYThGTVpFb243NGRDdmM0K3ExWEEySjJ0QnkycHdhVHFmCmhweHhk R0E5Smo1MFVKM1BENGJTVUVnTjh0TFowc2FuNDdsNVhUQUZMaTI0NTZjaVNsNW04c0thSGxH ZHQ5WG0KQUF0bVhxZVpWSVlYL1VGUzk2ZkR6ZjR4aEVtbS95N0xiWUVQUWRVZHh1NDd4QTVL aFRZcDVibHRGM1dZRHoxWQpnZDdneDA3QXV3cDdpdzdlTnZub0RUQWxLQWw4S1lEWnpiRE5D UUdFYnBZM2VmWkl2UGRlSStGV1FONFcra2doCnkrUDZhdTZQcklJaFlyYWV1YTdYRGRiMkxT MWVuM1NzbUUzUWpxZlJxSS9BMnVlOEpNd3N2WGUvV0szOEV6czYKeDc0aVRhcUkzQUZINmls QWhEcXBNbmQvbXNTRVNORnQ3NkRpTzFaS1FNcjlhbVZQa25qZlBtSklTcWRoZ0IxRApsRWR3 MzRzUk9mNlY4bVp3MHhmcVQ2UEtFNDZMY0ZlZnpzMGtiZzRHT1JmOHZqRzJTZjF0azVlVThN Qml5Ti9iClowM2JLTmpOWU1wT0REUVF3dVA4NGtZTGtYMndCeHhNQWhCeHdiRFZadWR6eERa SjFDMlZYdWpDT0pWeHEya2wKakJNOUVUWXVVR3FkNzVBVzJMWHJMdzYrTXVJc0hGQVlBZ1Jy NytLY3dEZ0JBZndoUEJZWDM0blNTaUhsbUxDKwpLYUhMZUNMRjVaSTJ2S20zSEVlQ1R0bE9n N3haRU9OZ3d6TCtmZEtvK0Q2U29DOFJSeEpLczhhM3NWZkk0dDZDCm5yUXp2SmJCbjZneGRn Q3U1aTI5SjFRQ1lyQ1l2cWwyVXlGUEFLK2RvOTkvMWpPWFQ0bTI4MzZqMXdBUkFRQUIKdENC UVlYVnNJRVZuWjJWeWRDQThaV2RuWlhKMFFHTnpMblZqYkdFdVpXUjFQb2tDUGdRVEFRSUFL QVVDVElCeQpaQUliQXdVSkVzd0RBQVlMQ1FnSEF3SUdGUWdDQ1FvTEJCWUNBd0VDSGdFQ0Y0 QUFDZ2tRN1pmcERtS3FmalJSCkd3LytJajAzZGhZZllsL2dYVlJpdXpWMWdHcmJIayt0bmZy SS9DN2ZBZW9GelE1dFZnVmluU2hhUGtabzBIVFAKZjE4eDZJREVkQWlPOE1xbzF5cDBDdEht ekdNQ0o1MG80R3JnZmpscjZnLyt2dEVPS2JobGVzek4yWHBKdnB3TQoyUWdHdm4vbGFUTFV1 OFBIOWFSV1RzN3FKSlpLS0tBYjRzeFljOTJGZWhQdTZGT0QwZERpeWhsREFxNGxPVjJtCmRC cHpRYmlvam9aelFMTVF3anBnQ1RLMjU3MmVLOUVPRVF5U1VUaFhyU0l6NkFTZW5wNE5ZVEZI czl0dUpRdlgKazlnWkRkUFNsM2JwKzQ3ZEd4bHhFV0xwQklNN3pJT053NGtzNGF6Z1Q4bnZE WnhBNUlaSHR2cUJsSkxCT2JZWQowTGU2MVdwMHkzVGxCRGgycWRLOGVZTDQyNlc0c2NFTVN1 aWc1Z2I4T0F0UWlCVzZrMnNHVXh4ZWl2OG92V3U4CllBWmdLSmZ1b1dJK3VSbk1FZGRydVk4 SnNvTTU0S2FLdlppa2tLczJiZzFuZHRMVnpIcEo2cUZaQzdRVmplSFUKaDYvQm1ndmRqV1Ba WUZUdE4rS0E5Q1dYM0dRS0tnTjN1dTk4OHl6bkQ3TG5COThUNEVVSDFIQS9HbmZCcU1WMQpn cHpUdlBjNHFWUWluQ21Ja0VGcDgzemwrRzVmQ2pKSjNXN2l2ekNuWW80S2hLTHBGVW05N29r VEtSMkxXM3haCnpFVzRjTFNXTzM4N01USzNDekRPeDVxZTZzNGE5MVp1Wk0vai9UUWRUTERh cU5uODNrQTRIcTQ4VUhYWXhjSWgKK05kOGsvM3c2bEZ1b0swd3JPRml5d2pMeCswdXI1am1t YmVjQkdIYzF4ZGhBRkc1QWcwRVRJQnlaQUVRQUthRgo2NzhUOXd5SDR3alRyVjFQejNjREVv U25WLzBaVXJPVDM3cDFkY0d5ai9JWHExeDY3MEhSVmFoQW1rMHNacFljCjI1UEY5RDVHUFlI RldsTmp1UFU5NnJEbmRYQjNoZWRtQlJoTGRDNGJBWGpJNERWK2JtZFZlK3EvSU1ubFpSYVYK bG05RWlNQ1ZBUjZ3MTNzUmV1N3FYa1c5cjNSd1kyQXpYc2twL3RBZTRCUktyMVptYnZpMm5i blE2ZXBFQzQycgpSYngwQjFFaGpiSVFaNUpIR2syNGlQVDdMZEJnbk5tb3M1d1lqendObGtN UUQ1VDBZZHpoazdKK1V4d0E1bTQ2Cm1PaFJEQzJyRlYvQTBnbTVUTHk4RFhqdi9Fc2M0Z1lu WWFpNlNRcW5VRVZoNUx1VjhZQ0pCbmlqcytUaXc3MXgKMWljbW42eEdJNDVFdWdKT2dlYyty THlwWWdwVnA0eDBISTVUODhxQlJZQ2t4SDNLZzhRbytFV05BOUE0TFJROQpEWDhuam9uYTBn ZjBzMDN0b2NLOGtCTjY2VW9xcVB0SEJuYzRlTWdCeW1DZmxLMTJlS2ZkMllZeG55ZzljWmF6 CldBNVZzbHZUeHBtNzZoYmc1b2lBRUgvVmcvOE14SHlBblBoZnJnd3lQcm1KRWNWQmFmZHNw Sm5ZUXhCWU5jbzIKTEZQSWhsT3ZXaDhyNGF0K3MrTTNMYjI2b1VUY3psZ2RXMVNmM1NEQTc3 Qk1SbkYwRlF5RSs3QXpWNzlNQk40eQpraXFhZXpReHRhRjFGeS90dmtoZmZTbzh1K2R3RzBF Z0poK3RlMzhnVGNJU1ZyMEdJUHBsTHo2WWhqcmJIclBSCkYxQ041VXVMOURCR2p4dU4zNVJM TlZFZnRhNlJVRmxSNk5jdFRqdnJBQkVCQUFHSkFpVUVHQUVDQUE4RkFreUEKY21RQ0d3d0ZD UkxNQXdBQUNna1E3WmZwRG1LcWZqU3JIQS8rS3pBS3ZUeFJoQTlNV05MeEl5SjdTNXVKMTZn cwpUM29DalpyQktHRWhLTU9HWDRPMEdBNlZPRXJ5TzdRUkNDWWFoM294U0czOElBbk5laXdK WGdVOUJ6a2s4NVVHCmJQRWQ3SEdGL1ZTZUhDUXdXb3U2anFVRFRTRHZuOVloTlRkRzBLWFBN NzRhQyt4cjJab3cxTzJtaFhpaGdXS0QKMER3KzBMWVBuVU9zUTBLT0Z4SFhYWUhtUnJTMU9a UFU1OUJMdmMrVFJoSWhhZlNIS0x3YlhLKzZja2t4Qng2aAo4ejVjY3BHMFFzNGJGaGRGWW5G ckVpZURMb0dtbkUyWUxoZFY2c3dKOVZOQ1M2cExpRW9oVDNmbTdhWG0xNXRaCk9JeXpNWmhI UlNBUGJsWHhRMFpTV2pxOG9ScmNZTkZ4YzRXMVVScEFrQkNPWUpvWHZRZkQ1TDNscUFsOFRD cUQKVXpZeGhIL3RKaGJEZEhycUhINzY3amFEYVRCMStUYWxwLzJBTUt3Y1hOT2Rpa2xHeGJt SFZHNllHbDZnOExyYgpzdTlOWkVJNHlMbEh6dWlrdGhKV2d6KzN2WmhWR3lObHQrSE5Jb0Y2 Q2pETDJvbXU1Y0VxNFJESE00NFFxUGs2Cmw3TzBwVXZOMW1UNEIrUzFiMDhSS3BxbS9mZjAx NUUzN0hOVi9waUl2Smx4R0FZejhQU2Z1R0NCMXRoTVlxbG0KZ2RoZDkvQmFiR0ZiR0dZSEE2 VTQvVDV6cVUrZjZ4SHkxU3NBUVoxTVNLbEx3ZWtCSVQrNC9jTFJHcUNIam5WMApxNUgvVDZh N3Q1bVBrYnpTck9MU280cHVqK0lUb05qWXlZSURCV3pobEExOWF2T2ErcnZVam1IdEQzc0ZO N2NYCld0a0dvaThidU5jYnk0VT0KPUFMNm8KLS0tLS1FTkQgUEdQIFBVQkxJQyBLRVkgQkxP Q0stLS0tLQo= Organization: UCLA Computer Science Department Message-ID: <9616f039-8109-ec1b-bb0a-9d229c8d30e5@cs.ucla.edu> Date: Sat, 2 May 2020 12:47:49 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <72ead2e2-85e5-723f-ecc8-63bf7d610c57@jguk.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 41001 Cc: 41001@debbugs.gnu.org, Eric Blake X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 5/2/20 6:26 AM, Jonny Grant wrote: > If developers have race conditions in their shell scripts I've personally fixed a bug in the GNU mkdir command that was triggered by such races. Core utilities should be reliable even when these races are happening. From debbugs-submit-bounces@debbugs.gnu.org Sat May 02 18:41:53 2020 Received: (at 41001) by debbugs.gnu.org; 2 May 2020 22:41:53 +0000 Received: from localhost ([127.0.0.1]:54098 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jV0pV-0000hu-B6 for submit@debbugs.gnu.org; Sat, 02 May 2020 18:41:53 -0400 Received: from mail-wm1-f48.google.com ([209.85.128.48]:51488) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jV0pS-0000hd-IA for 41001@debbugs.gnu.org; Sat, 02 May 2020 18:41:51 -0400 Received: by mail-wm1-f48.google.com with SMTP id x4so4155395wmj.1 for <41001@debbugs.gnu.org>; Sat, 02 May 2020 15:41:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jguk.org; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=yDUK8TqqAUw93QiIFxb8Tvrch+1LAxOuX/oVzENk5zA=; b=AxPa2H4QYIkHpxhagHYUbYBVIygLEQXDNev7xG5d1hGV8rBdUuo3osbrtbBGrNC9wj bPLr8gDEDYeEPNUFcRi4hOamlP2Hf0VzOKkGw519dUwAn+fA3fFgyxyp6M4ZiQx4KiSw zpJkbqLvPCY/FJBQyE6g69JA3cc1o7m13t6hfDZQyuaIAVErH0DxVL0kxjGdgNAQxa00 FovDaDTekG64LkF2Ijm0u+KHSVpizZVmeKRJ379HUu46NZZ5r6mlA2LsvehwPVoYUbBQ dlbaW4r8w1Ov67F9+eY6gOE8BmIsIhLspXrsVSN+VUzJ7QMg7po9/6rco7YYTYdYakIO KFzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=yDUK8TqqAUw93QiIFxb8Tvrch+1LAxOuX/oVzENk5zA=; b=YyPoYb3YbVY8DhjXp/mq0V2jX+Tyvz6tjo0VbWH2JzmTVXkcJ3oZIPgC+vZUvWj8+s FfFPiAbjFRY7BKCwKYqYnFwx7zdO2ab9fd9zf25XKZ6yQhjyQevesVhGB16v8dMbBY4j g9Yu9t5l+4c9U7KDoO7tw6LOY9Fyqf3MdzUqgKg8G6miEnYsKIWhN64TPN4p1s3YNf/x JsQMRi8GnxosZP4Rg9SMW2vIOi01/PZEZKLx+wb4qetN9EqCninwXqcNhIrUHAWjva7S bm6RtIX1JRt5TGclwJxt6+rd5/HIB/GzZ56QOnbqOMW79W8+sOtQaYV1HUVTDXd9vteJ WUsA== X-Gm-Message-State: AGi0PuZ+Na6RwSMlf1+5NDiyEJ3XLK/FIrJ8l7M90+8BiXL8bn+I8OmS Ry3ec+9+EGLNIugjphldSUcCWw== X-Google-Smtp-Source: APiQypInxQmSgokwxRUwjSnenEfwixSANZvpeLgrIszz09jkMMGwWgTP9esqmcmlGaBL/tg8SNwKaw== X-Received: by 2002:a05:600c:1109:: with SMTP id b9mr6417631wma.116.1588459304545; Sat, 02 May 2020 15:41:44 -0700 (PDT) Received: from [192.168.0.12] (cpc87281-slou4-2-0-cust47.17-4.cable.virginm.net. [92.236.12.48]) by smtp.gmail.com with ESMTPSA id y31sm3424450wrd.83.2020.05.02.15.41.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 02 May 2020 15:41:43 -0700 (PDT) Subject: =?UTF-8?Q?Re=3a_bug=2341001=3a_mkdir=3a_cannot_create_directory_?= =?UTF-8?B?4oCYdGVzdOKAmTogRmlsZSBleGlzdHM=?= To: Paul Eggert References: <40df8619-2aec-9660-14f2-b674fc0e6d14@jguk.org> <3e663b56-7771-20c6-45aa-c709a7ee7296@redhat.com> <6f605632-0314-cb5d-d722-599d3e578e80@jguk.org> <232f6665-7edd-842c-ac9d-4fd2d6d86368@cs.ucla.edu> <48d4fbd5-3e57-00b3-9a3e-3f0795fa743f@cs.ucla.edu> <72ead2e2-85e5-723f-ecc8-63bf7d610c57@jguk.org> <9616f039-8109-ec1b-bb0a-9d229c8d30e5@cs.ucla.edu> From: Jonny Grant Message-ID: Date: Sat, 2 May 2020 23:41:43 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <9616f039-8109-ec1b-bb0a-9d229c8d30e5@cs.ucla.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41001 Cc: 41001@debbugs.gnu.org, Eric Blake X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 02/05/2020 20:47, Paul Eggert wrote: > On 5/2/20 6:26 AM, Jonny Grant wrote: >> If developers have race conditions in their shell scripts > > I've personally fixed a bug in the GNU mkdir command that was triggered by such > races. Core utilities should be reliable even when these races are happening. Is a more accurate strerror considered unreliable? Current: mkdir: cannot create directory ‘test’: File exists Proposed: mkdir: cannot create directory ‘test’: Is a directory Cheers, Jonny From debbugs-submit-bounces@debbugs.gnu.org Sat May 02 19:13:14 2020 Received: (at 41001) by debbugs.gnu.org; 2 May 2020 23:13:14 +0000 Received: from localhost ([127.0.0.1]:54131 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jV1Jq-0001Yh-4E for submit@debbugs.gnu.org; Sat, 02 May 2020 19:13:14 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:50696) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jV1Jn-0001YT-Cl for 41001@debbugs.gnu.org; Sat, 02 May 2020 19:13:13 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 922941600E1; Sat, 2 May 2020 16:13:05 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id VjBs4YtBSw_S; Sat, 2 May 2020 16:13:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id A96441600E4; Sat, 2 May 2020 16:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id WKiyvcgY1nfO; Sat, 2 May 2020 16:13:04 -0700 (PDT) Received: from [192.168.1.9] (cpe-23-242-74-103.socal.res.rr.com [23.242.74.103]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 6560B1600E1; Sat, 2 May 2020 16:13:04 -0700 (PDT) Subject: =?UTF-8?Q?Re=3a_bug=2341001=3a_mkdir=3a_cannot_create_directory_?= =?UTF-8?B?4oCYdGVzdOKAmTogRmlsZSBleGlzdHM=?= To: Jonny Grant References: <40df8619-2aec-9660-14f2-b674fc0e6d14@jguk.org> <3e663b56-7771-20c6-45aa-c709a7ee7296@redhat.com> <6f605632-0314-cb5d-d722-599d3e578e80@jguk.org> <232f6665-7edd-842c-ac9d-4fd2d6d86368@cs.ucla.edu> <48d4fbd5-3e57-00b3-9a3e-3f0795fa743f@cs.ucla.edu> <72ead2e2-85e5-723f-ecc8-63bf7d610c57@jguk.org> <9616f039-8109-ec1b-bb0a-9d229c8d30e5@cs.ucla.edu> From: Paul Eggert Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkV5QWNtUUJFQURB QXlIMnhvVHU3cHBHNUQzYThGTVpFb243NGRDdmM0K3ExWEEySjJ0QnkycHdhVHFmCmhweHhk R0E5Smo1MFVKM1BENGJTVUVnTjh0TFowc2FuNDdsNVhUQUZMaTI0NTZjaVNsNW04c0thSGxH ZHQ5WG0KQUF0bVhxZVpWSVlYL1VGUzk2ZkR6ZjR4aEVtbS95N0xiWUVQUWRVZHh1NDd4QTVL aFRZcDVibHRGM1dZRHoxWQpnZDdneDA3QXV3cDdpdzdlTnZub0RUQWxLQWw4S1lEWnpiRE5D UUdFYnBZM2VmWkl2UGRlSStGV1FONFcra2doCnkrUDZhdTZQcklJaFlyYWV1YTdYRGRiMkxT MWVuM1NzbUUzUWpxZlJxSS9BMnVlOEpNd3N2WGUvV0szOEV6czYKeDc0aVRhcUkzQUZINmls QWhEcXBNbmQvbXNTRVNORnQ3NkRpTzFaS1FNcjlhbVZQa25qZlBtSklTcWRoZ0IxRApsRWR3 MzRzUk9mNlY4bVp3MHhmcVQ2UEtFNDZMY0ZlZnpzMGtiZzRHT1JmOHZqRzJTZjF0azVlVThN Qml5Ti9iClowM2JLTmpOWU1wT0REUVF3dVA4NGtZTGtYMndCeHhNQWhCeHdiRFZadWR6eERa SjFDMlZYdWpDT0pWeHEya2wKakJNOUVUWXVVR3FkNzVBVzJMWHJMdzYrTXVJc0hGQVlBZ1Jy NytLY3dEZ0JBZndoUEJZWDM0blNTaUhsbUxDKwpLYUhMZUNMRjVaSTJ2S20zSEVlQ1R0bE9n N3haRU9OZ3d6TCtmZEtvK0Q2U29DOFJSeEpLczhhM3NWZkk0dDZDCm5yUXp2SmJCbjZneGRn Q3U1aTI5SjFRQ1lyQ1l2cWwyVXlGUEFLK2RvOTkvMWpPWFQ0bTI4MzZqMXdBUkFRQUIKdENC UVlYVnNJRVZuWjJWeWRDQThaV2RuWlhKMFFHTnpMblZqYkdFdVpXUjFQb2tDUGdRVEFRSUFL QVVDVElCeQpaQUliQXdVSkVzd0RBQVlMQ1FnSEF3SUdGUWdDQ1FvTEJCWUNBd0VDSGdFQ0Y0 QUFDZ2tRN1pmcERtS3FmalJSCkd3LytJajAzZGhZZllsL2dYVlJpdXpWMWdHcmJIayt0bmZy SS9DN2ZBZW9GelE1dFZnVmluU2hhUGtabzBIVFAKZjE4eDZJREVkQWlPOE1xbzF5cDBDdEht ekdNQ0o1MG80R3JnZmpscjZnLyt2dEVPS2JobGVzek4yWHBKdnB3TQoyUWdHdm4vbGFUTFV1 OFBIOWFSV1RzN3FKSlpLS0tBYjRzeFljOTJGZWhQdTZGT0QwZERpeWhsREFxNGxPVjJtCmRC cHpRYmlvam9aelFMTVF3anBnQ1RLMjU3MmVLOUVPRVF5U1VUaFhyU0l6NkFTZW5wNE5ZVEZI czl0dUpRdlgKazlnWkRkUFNsM2JwKzQ3ZEd4bHhFV0xwQklNN3pJT053NGtzNGF6Z1Q4bnZE WnhBNUlaSHR2cUJsSkxCT2JZWQowTGU2MVdwMHkzVGxCRGgycWRLOGVZTDQyNlc0c2NFTVN1 aWc1Z2I4T0F0UWlCVzZrMnNHVXh4ZWl2OG92V3U4CllBWmdLSmZ1b1dJK3VSbk1FZGRydVk4 SnNvTTU0S2FLdlppa2tLczJiZzFuZHRMVnpIcEo2cUZaQzdRVmplSFUKaDYvQm1ndmRqV1Ba WUZUdE4rS0E5Q1dYM0dRS0tnTjN1dTk4OHl6bkQ3TG5COThUNEVVSDFIQS9HbmZCcU1WMQpn cHpUdlBjNHFWUWluQ21Ja0VGcDgzemwrRzVmQ2pKSjNXN2l2ekNuWW80S2hLTHBGVW05N29r VEtSMkxXM3haCnpFVzRjTFNXTzM4N01USzNDekRPeDVxZTZzNGE5MVp1Wk0vai9UUWRUTERh cU5uODNrQTRIcTQ4VUhYWXhjSWgKK05kOGsvM3c2bEZ1b0swd3JPRml5d2pMeCswdXI1am1t YmVjQkdIYzF4ZGhBRkc1QWcwRVRJQnlaQUVRQUthRgo2NzhUOXd5SDR3alRyVjFQejNjREVv U25WLzBaVXJPVDM3cDFkY0d5ai9JWHExeDY3MEhSVmFoQW1rMHNacFljCjI1UEY5RDVHUFlI RldsTmp1UFU5NnJEbmRYQjNoZWRtQlJoTGRDNGJBWGpJNERWK2JtZFZlK3EvSU1ubFpSYVYK bG05RWlNQ1ZBUjZ3MTNzUmV1N3FYa1c5cjNSd1kyQXpYc2twL3RBZTRCUktyMVptYnZpMm5i blE2ZXBFQzQycgpSYngwQjFFaGpiSVFaNUpIR2syNGlQVDdMZEJnbk5tb3M1d1lqendObGtN UUQ1VDBZZHpoazdKK1V4d0E1bTQ2Cm1PaFJEQzJyRlYvQTBnbTVUTHk4RFhqdi9Fc2M0Z1lu WWFpNlNRcW5VRVZoNUx1VjhZQ0pCbmlqcytUaXc3MXgKMWljbW42eEdJNDVFdWdKT2dlYyty THlwWWdwVnA0eDBISTVUODhxQlJZQ2t4SDNLZzhRbytFV05BOUE0TFJROQpEWDhuam9uYTBn ZjBzMDN0b2NLOGtCTjY2VW9xcVB0SEJuYzRlTWdCeW1DZmxLMTJlS2ZkMllZeG55ZzljWmF6 CldBNVZzbHZUeHBtNzZoYmc1b2lBRUgvVmcvOE14SHlBblBoZnJnd3lQcm1KRWNWQmFmZHNw Sm5ZUXhCWU5jbzIKTEZQSWhsT3ZXaDhyNGF0K3MrTTNMYjI2b1VUY3psZ2RXMVNmM1NEQTc3 Qk1SbkYwRlF5RSs3QXpWNzlNQk40eQpraXFhZXpReHRhRjFGeS90dmtoZmZTbzh1K2R3RzBF Z0poK3RlMzhnVGNJU1ZyMEdJUHBsTHo2WWhqcmJIclBSCkYxQ041VXVMOURCR2p4dU4zNVJM TlZFZnRhNlJVRmxSNk5jdFRqdnJBQkVCQUFHSkFpVUVHQUVDQUE4RkFreUEKY21RQ0d3d0ZD UkxNQXdBQUNna1E3WmZwRG1LcWZqU3JIQS8rS3pBS3ZUeFJoQTlNV05MeEl5SjdTNXVKMTZn cwpUM29DalpyQktHRWhLTU9HWDRPMEdBNlZPRXJ5TzdRUkNDWWFoM294U0czOElBbk5laXdK WGdVOUJ6a2s4NVVHCmJQRWQ3SEdGL1ZTZUhDUXdXb3U2anFVRFRTRHZuOVloTlRkRzBLWFBN NzRhQyt4cjJab3cxTzJtaFhpaGdXS0QKMER3KzBMWVBuVU9zUTBLT0Z4SFhYWUhtUnJTMU9a UFU1OUJMdmMrVFJoSWhhZlNIS0x3YlhLKzZja2t4Qng2aAo4ejVjY3BHMFFzNGJGaGRGWW5G ckVpZURMb0dtbkUyWUxoZFY2c3dKOVZOQ1M2cExpRW9oVDNmbTdhWG0xNXRaCk9JeXpNWmhI UlNBUGJsWHhRMFpTV2pxOG9ScmNZTkZ4YzRXMVVScEFrQkNPWUpvWHZRZkQ1TDNscUFsOFRD cUQKVXpZeGhIL3RKaGJEZEhycUhINzY3amFEYVRCMStUYWxwLzJBTUt3Y1hOT2Rpa2xHeGJt SFZHNllHbDZnOExyYgpzdTlOWkVJNHlMbEh6dWlrdGhKV2d6KzN2WmhWR3lObHQrSE5Jb0Y2 Q2pETDJvbXU1Y0VxNFJESE00NFFxUGs2Cmw3TzBwVXZOMW1UNEIrUzFiMDhSS3BxbS9mZjAx NUUzN0hOVi9waUl2Smx4R0FZejhQU2Z1R0NCMXRoTVlxbG0KZ2RoZDkvQmFiR0ZiR0dZSEE2 VTQvVDV6cVUrZjZ4SHkxU3NBUVoxTVNLbEx3ZWtCSVQrNC9jTFJHcUNIam5WMApxNUgvVDZh N3Q1bVBrYnpTck9MU280cHVqK0lUb05qWXlZSURCV3pobEExOWF2T2ErcnZVam1IdEQzc0ZO N2NYCld0a0dvaThidU5jYnk0VT0KPUFMNm8KLS0tLS1FTkQgUEdQIFBVQkxJQyBLRVkgQkxP Q0stLS0tLQo= Organization: UCLA Computer Science Department Message-ID: <4752255f-d934-fa9e-ddfc-3a9983126746@cs.ucla.edu> Date: Sat, 2 May 2020 16:13:03 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 41001 Cc: 41001@debbugs.gnu.org, Eric Blake X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 5/2/20 3:41 PM, Jonny Grant wrote: > Is a more accurate strerror considered unreliable? >=20 > Current: > mkdir: cannot create directory =E2=80=98test=E2=80=99: File exists >=20 > Proposed: > mkdir: cannot create directory =E2=80=98test=E2=80=99: Is a directory I don't understand this comment. As I understand it you're proposing a ch= ange to the mkdir command not a change to the strerror library function, and the = change you're proposing would introduce a race condition to the mkdir command. A better fix would be to change the mkdir system call so that it sets err= no to EISDIR in this situation. This would fix not only the mkdir utility, but = also lots of other programs; and it wouldn't introduce a race condition. So if= you're interested in getting the problem fixed, I suggest that you propose such = a change to the Linux kernel developers. From debbugs-submit-bounces@debbugs.gnu.org Sun May 03 09:02:39 2020 Received: (at 41001) by debbugs.gnu.org; 3 May 2020 13:02:39 +0000 Received: from localhost ([127.0.0.1]:54873 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jVEGU-0007so-Sc for submit@debbugs.gnu.org; Sun, 03 May 2020 09:02:39 -0400 Received: from mail-wm1-f67.google.com ([209.85.128.67]:53881) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jVEGS-0007sa-UM for 41001@debbugs.gnu.org; Sun, 03 May 2020 09:02:38 -0400 Received: by mail-wm1-f67.google.com with SMTP id k12so5251263wmj.3 for <41001@debbugs.gnu.org>; Sun, 03 May 2020 06:02:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jguk.org; s=google; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=k1JO1mD+zUpOODdaip0KK1mswcu+VDqmXb+CmnjS9NU=; b=lpVSg+bWjIW/kwTS7yHO75TaU+8ml7f0lPN9R5nTlD5HusuwApxQWZdO2jWKR6qwBU N+MUAXg74Cg8pElzrFEikKsFh5ygnjmujbnSV4hxdxqHGGIhAOCsDWhfX05Y2jhvfsI5 5OxnQ8kLMu295K7+FO09yvs3EClumQsEISBNeaw3Wre1Xtdmy2pEMQ4B3ZAuuMbpgoG6 /ivhaQVO6Q5Mu7qyadxiFFJpnfAnq9a1rsR1gT/YFdTTu53PT2vbMCykjPfpFu9mb56F 2Z6vONwc62pCkbCI817q5A1ky+n0fFFgbB6LOVkqjEE6XE/Z5lS51e5JP0Te45OCCIyo 02CA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=k1JO1mD+zUpOODdaip0KK1mswcu+VDqmXb+CmnjS9NU=; b=WY/XcHw5BJRRdibwDGlnwiwFV/9k0Lf3etBJytBnNGwcyUkVBixnrhXLwz9gh082+y Mnc+2kUqLiRVtIWNcIeBPP2HUHKhyE76+WNV2xXYk4LRRWYERUkyQyHB4kv0mjKHmztV QtlYFo+7AyniyldJzuSW4XVhd6al+c1Po2t8iFvra1k6LUcP8o6SbkUuADUIndP/xu5l Ff2ewm7ZYaReTkEkFpX6FcCqU2z+QoMtfgyfETdLUWG942JmFhV9WSPp+G9XTcTOLbAq Ajs7StW4PAxieh2v+Tnk0oh3uGDF4fUkyPWZpu94OQ9HcCv7BGvJzmF1Rk8GSsrNJ3jS jAcQ== X-Gm-Message-State: AGi0PuaeROp+1F3crDZc+Sj5Cql17hQgFGdYRPLUy2bW1/LfJ9wrYkuJ y279yLIzMuyfM0kKOVX+jEpI/Q== X-Google-Smtp-Source: APiQypLW3n6h4HNw2JjaaIjW/s7qPb/6mMofkD5q9w8xi0ExxErSRJNvvjMuz0lkvxPbekeioR/bPw== X-Received: by 2002:a7b:c74d:: with SMTP id w13mr9055953wmk.36.1588510950912; Sun, 03 May 2020 06:02:30 -0700 (PDT) Received: from [192.168.0.12] (cpc87281-slou4-2-0-cust47.17-4.cable.virginm.net. [92.236.12.48]) by smtp.gmail.com with ESMTPSA id y70sm9330720wmc.36.2020.05.03.06.02.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 03 May 2020 06:02:30 -0700 (PDT) From: Jonny Grant Subject: =?UTF-8?Q?Re=3a_bug=2341001=3a_mkdir=3a_cannot_create_directory_?= =?UTF-8?B?4oCYdGVzdOKAmTogRmlsZSBleGlzdHM=?= To: Paul Eggert References: <40df8619-2aec-9660-14f2-b674fc0e6d14@jguk.org> <3e663b56-7771-20c6-45aa-c709a7ee7296@redhat.com> <6f605632-0314-cb5d-d722-599d3e578e80@jguk.org> <232f6665-7edd-842c-ac9d-4fd2d6d86368@cs.ucla.edu> <48d4fbd5-3e57-00b3-9a3e-3f0795fa743f@cs.ucla.edu> <72ead2e2-85e5-723f-ecc8-63bf7d610c57@jguk.org> <9616f039-8109-ec1b-bb0a-9d229c8d30e5@cs.ucla.edu> <4752255f-d934-fa9e-ddfc-3a9983126746@cs.ucla.edu> Message-ID: Date: Sun, 3 May 2020 14:02:29 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <4752255f-d934-fa9e-ddfc-3a9983126746@cs.ucla.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41001 Cc: 41001@debbugs.gnu.org, Eric Blake X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hi! On 03/05/2020 00:13, Paul Eggert wrote: > On 5/2/20 3:41 PM, Jonny Grant wrote: >> Is a more accurate strerror considered unreliable? >> >> Current: >> mkdir: cannot create directory ‘test’: File exists >> >> Proposed: >> mkdir: cannot create directory ‘test’: Is a directory > > I don't understand this comment. As I understand it you're proposing a change to > the mkdir command not a change to the strerror library function, and the change > you're proposing would introduce a race condition to the mkdir command. As the mkdir error returned to the shell is the same, I don't feel the difference between the words "File exists" and "Is a directory" on the terminal can be considered a race condition. You're right, there will be a race condition where two processes are both creating and deleting the same files. Any software which is creating and deleting the same directories in parallel will encounter a multitude of errors - all bets are off. > A better fix would be to change the mkdir system call so that it sets errno to > EISDIR in this situation. This would fix not only the mkdir utility, but also > lots of other programs; and it wouldn't introduce a race condition. So if you're > interested in getting the problem fixed, I suggest that you propose such a > change to the Linux kernel developers. Yes, if Linux kernel developers would deviate from POSIX. I emailed linux-ext4@vger.kernel.org the lines of code to change. I'm not confident it will get in, even harder to get into POSIX I expect. ext4_match() is what would need to be updated to check if an entry is a directory https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/fs/ext4/namei.c Cheers, Jonny From debbugs-submit-bounces@debbugs.gnu.org Mon May 04 15:32:52 2020 Received: (at 41001) by debbugs.gnu.org; 4 May 2020 19:32:52 +0000 Received: from localhost ([127.0.0.1]:33956 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jVgpg-0004oK-9a for submit@debbugs.gnu.org; Mon, 04 May 2020 15:32:52 -0400 Received: from havoc.proulx.com ([96.88.95.61]:49284) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jVgpS-0004nq-ES for 41001@debbugs.gnu.org; Mon, 04 May 2020 15:32:51 -0400 Received: from joseki.proulx.com (localhost [127.0.0.1]) by havoc.proulx.com (Postfix) with ESMTP id BC952134; Mon, 4 May 2020 13:32:32 -0600 (MDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proulx.com; s=dkim2048; t=1588620752; bh=wFugsXmAhUN2/RvdapJWhkNQhfO6PGgWR8XGqZ1L3TY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=KuBoK0veUH/bkHE/2GlkDDMHBn+5mBfpXOas0HKoOKhuZ+PKP/6wxpoNIprquXRrR Uq2sVaS8YKlaa3hOvLZsKDCDoH5kCJgkGvn4qWRfmB0lpllQX04MpcDYWtOYo46mRh 2M6fHitxSabFp5YhBY8S2l6rwIXT5Ng9QykWeSKBwtn9bWTiGk8nuFHtu7BJqOVK73 RFO7psu4qvLUxSXT2Hh7Pg05YNI4LUZ81vfaAaTxSPRFAYtBXZ3hKs3EbaQ0gvFw3N 4XsH8dE8RMD5oFvDT1MgDF/ZULDoCjr5A8R3gjO8dCbxAp3bhe8yhErO1oTPCCZqpr xYrJ3RePHg5kA== Received: from hysteria.proulx.com (hysteria.proulx.com [192.168.230.119]) by joseki.proulx.com (Postfix) with ESMTP id 8CDAC21157; Mon, 4 May 2020 13:32:32 -0600 (MDT) Received: by hysteria.proulx.com (Postfix, from userid 1000) id 6D7532DC8C; Mon, 4 May 2020 13:32:32 -0600 (MDT) Date: Mon, 4 May 2020 13:32:32 -0600 From: Bob Proulx To: Jonny Grant Subject: Re: bug#41001: mkdir: cannot =?utf-8?Q?cre?= =?utf-8?B?YXRlIGRpcmVjdG9yeSDigJh0ZXN04oCZOg==?= File exists Message-ID: <20200504123734454980598@bob.proulx.com> References: <3e663b56-7771-20c6-45aa-c709a7ee7296@redhat.com> <6f605632-0314-cb5d-d722-599d3e578e80@jguk.org> <232f6665-7edd-842c-ac9d-4fd2d6d86368@cs.ucla.edu> <48d4fbd5-3e57-00b3-9a3e-3f0795fa743f@cs.ucla.edu> <72ead2e2-85e5-723f-ecc8-63bf7d610c57@jguk.org> <9616f039-8109-ec1b-bb0a-9d229c8d30e5@cs.ucla.edu> <4752255f-d934-fa9e-ddfc-3a9983126746@cs.ucla.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41001 Cc: 41001@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Jonny Grant wrote: > Paul Eggert wrote: > > Jonny Grant wrote: > > > Is a more accurate strerror considered unreliable? > > > > > > Current: > > > mkdir: cannot create directory ‘test’: File exists > > > > > > Proposed: > > > mkdir: cannot create directory ‘test’: Is a directory > > > > I don't understand this comment. As I understand it you're proposing a change to > > the mkdir command not a change to the strerror library function, and the change > > you're proposing would introduce a race condition to the mkdir command. > > As the mkdir error returned to the shell is the same, I don't feel the > difference between the words "File exists" and "Is a directory" on the > terminal can be considered a race condition. I read the message thread carefully and the proposal was to add an additional non-atomic stat(2) call to the logic. That sets up the race condition. The difference in the words of the error string is not the race condition. The race condition is created when trying to stat(2) the file to see why it failed. That can only be done as a separate action. That cannot be an atomic operation. That can only create a race condition. For the low level utilities it is almost always a bad idea to layer in additional system calls that are not otherwise there. Doing so almost always creates additional bugs. And then there will be new bug reports about those problems. And those will be completely valid. Try this experiment on your own. /tmp$ strace -e trace=mkdir mkdir foodir1 mkdir("foodir1", 0777) = 0 +++ exited with 0 +++ /tmp$ strace -e trace=mkdir mkdir foodir1 mkdir("foodir1", 0777) = -1 EEXIST (File exists) mkdir: cannot create directory ‘foodir1’: File exists +++ exited with 1 +++ The first mkdir("foodir1", 0777) call succeeded. The second mkdir("foodir1", 0777) call fail, returned -1, set errno = EEXIST, EEXIST is the error number for "File exists". Note that this output line: mkdir("foodir1", 0777) = -1 EEXIST (File exists) That line was entirely reported by the 'strace' command and is not any code related to the Coreutils mkdir command. The strace command reported the same "File exists" message as mkdir did later, due to the EEXIST error code. Let's try the same experiment with a file. And also with a pipe and a character device too. /tmp$ touch file1 /tmp$ strace -e trace=mkdir mkdir file1 mkdir("file1", 0777) = -1 EEXIST (File exists) mkdir: cannot create directory ‘file1’: File exists +++ exited with 1 +++ /tmp$ mkfifo fifo1 strace -e trace=mkdir mkdir fifo1 mkdir("fifo1", 0777) = -1 EEXIST (File exists) mkdir: cannot create directory ‘fifo1’: File exists +++ exited with 1 +++ /tmp$ sudo mknod char1 c 5 0 /tmp$ strace -e trace=mkdir mkdir char1 mkdir("char1", 0777) = -1 EEXIST (File exists) mkdir: cannot create directory ‘char1’: File exists +++ exited with 1 +++ And so we see that the kernel is returning the same EEXIST error code for *all* cases where a file previously exists. And it is correct because all of those are files. Because directories are files, pipes are files, and files are files. Everything is a file. Therefore EEXIST is a correct error message. In order to correctly change the message being reported the change should be made in the kernel so that the kernel, which has the information at that time atomically, could report an error providing more detail than simply EEXIST. You have proposed that mkdir add a stat(2) system call to extract this additional information. > as it's easy enough to call stat() like other package maintainers > do, as you can see in binutils. *That* stat() addition creates the race condition. Adding a stat() call cannot be done atomically. It would need to be done either before the mkdir(), after the mkdir(), or both before and after. Let's see how that can go wrong. Let's say we stat(), does not exist, we continue with mkdir(), fails with EEXIST because another process got there first. So then we stat() again and by that time the other process has already finished processing and removed the directory again. A system call trace would look like this. lstat("foodir1", 0x7ffcafc12800) = -1 ENOENT (No such file or directory) mkdir("foodir1", 0777) = -1 EEXIST (File exists) lstat("foodir1", 0x7ffcafc12800) = -1 ENOENT (No such file or directory) Okay. That's confusing. The only value in hand being EEXIST then that is the error to be reported. If this were repeated many times then sometimes we would catch it as an actual directory. lstat("foodir1", 0x7ffcafc12800) = -1 ENOENT (No such file or directory) mkdir("foodir1", 0777) = -1 EEXIST (File exists) lstat("foodir1", {st_mode=S_IFDIR|0775, st_size=40, ...}) = 0 In that case the proposal is to report it as EISDIR. If we were to set up two processes coordinating using a directory as a semaphore and printing out the errors then we would see a stream of output that is sometimes the creation of the directory, sometimes the failure since a directory already exists, and sometimes a failure because it is a file. Race condition. That would be extremely confusing! I assure you the valid bug reports would be swift and correctly merciless! And there is another possibility that is also bad too. We stat(), does not exist, we continue with mkdir(), fails with EEXIST because another process got there first creating it as a file. So then we stat() again and by that time the other process has removed the file and replaced it with a fifo device node. lstat("file1", 0x7ffdedf9aca0) = -1 ENOENT (No such file or directory) mkdir("file1", 0777) = -1 EEXIST (File exists) lstat("fifo1", {st_mode=S_IFIFO|0664, st_size=0, ...}) = 0 At that point the reason the mkdir actually failed was that it was a file but the second stat() would have a report that it was a fifo device which would be incorrect. Race condition. For the low level utilities it is almost always best to remain close to the kernel and report the actual error reported by the kernel. Constructing a layer in the low level utilities is almost always a bad idea. However in your own shell scripts if you wish to construct exactly this same layer that you are proposing then that is your prerogative. But it would open your program up to valid bug reports for when the race condition tripped one of the problem cases. > You're right, there will be a race condition where two processes are both > creating and deleting the same files. Any software which is creating and > deleting the same directories in parallel will encounter a multitude of > errors - all bets are off. I am glad that you agree. That is exactly why adding non-atomic operations to the low level utilities creating those race coditions is a bad idea. > > A better fix would be to change the mkdir system call so that it sets errno to > > EISDIR in this situation. This would fix not only the mkdir utility, but also > > lots of other programs; and it wouldn't introduce a race condition. So if you're > > interested in getting the problem fixed, I suggest that you propose such a > > change to the Linux kernel developers. > > Yes, if Linux kernel developers would deviate from POSIX. I emailed > linux-ext4@vger.kernel.org the lines of code to change. I am glad to see that you are following up in the right place. That place being in the kernel. It can't be addressed correctly in user space. > I'm not confident it will get in, even harder to get into POSIX I expect. > > ext4_match() is what would need to be updated to check if an entry is a > directory > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/fs/ext4/namei.c ext4? But what if I am using xfs? Does this then behave differently on ext4 versus ext3 versus xfs versus nfs4 versus... Well... You get the idea. Sometimes the only way to win is not to play. Is the current EEXIST really so bad that we would create additional problems just to avoid it? Simplest is almost always best. Bob From debbugs-submit-bounces@debbugs.gnu.org Tue May 05 14:36:43 2020 Received: (at 41001) by debbugs.gnu.org; 5 May 2020 18:36:43 +0000 Received: from localhost ([127.0.0.1]:37427 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jW2Qs-0007by-VF for submit@debbugs.gnu.org; Tue, 05 May 2020 14:36:43 -0400 Received: from mail-wr1-f67.google.com ([209.85.221.67]:39167) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jW2Qq-0007bk-VO for 41001@debbugs.gnu.org; Tue, 05 May 2020 14:36:42 -0400 Received: by mail-wr1-f67.google.com with SMTP id l18so3933363wrn.6 for <41001@debbugs.gnu.org>; Tue, 05 May 2020 11:36:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jguk.org; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=TshQIjBgIXGbtM4yy1F+TPic2IAihXPEQEyMZnHL9Zg=; b=nG5lbEaoFvtpmmVrUp834AEBiaq1qlrqOHEA2SiHH6XcjpGROc68J9+La6Suoa+KEH xuz5OV6eeVEx0kEiJnFzaPaVZu+UJfPzKid+/O/7SXUiU8VZELM1ibi5BL+h6TbrrD4x Yedt2dV1FqhAflEOgFVuAc8sdCgUX6IGQm6Iulvz6j84L9NVWb6HKwYBBLQulh1UnviE PhuVyrGpy2dmRN5HcvB1OB+ThcL4I6PTUORF80jQu50YhTt2IaGkVycnuYn+TLQb67+r nzAnO2khW0QNExipgz7yZ76u8wuv1qPNnN1PkF6roxJamM5a4MavRv9EvH+yJ46f0iWd zx6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=TshQIjBgIXGbtM4yy1F+TPic2IAihXPEQEyMZnHL9Zg=; b=X1GM1FSEJayo+dasUbHAiO3H7OoLr81c6+/Q4q6Cj3XronrvE7FOm9E3+8fbCt8K1A hXq+DQn5gmg1sbdHGfclO4kQWMhOF02NoTCnEA4qkUDYb/pUZpfNnM+1gHzCq0fAahxp UvqzjorPmpbEVx+9Mx9pSfVtAPNUWdjcxvPqNB0/TLw/+pk0ZBO2Od28Rti9oRmyr0qQ yrc+rOrehjrrOUmGLqtoeOvfhG90xQSfz4PoWcL0/SYKqI8w1d5YT2Z77Sah/2wfwikw Rq8xwd/aM2qCsHnyteVhjpqdnEZHJWj+DFju9Di6qM6hr4GaMC2oOdW6QBoG6QHCjXQt 2T/g== X-Gm-Message-State: AGi0PubrhAl8yeKAeBWdyaPzV2G+2MK5kdwHDGeyEXZm9q7C+FTSAZRR hfetJojFQnmjweS+IyH1On2cl9rBDnA= X-Google-Smtp-Source: APiQypJBPMLOW71akyxq47P5R76sCuXr970DmnKgpPn6+lvZpqB+htQBbuHnMRTKQblxX7FoOu+FiQ== X-Received: by 2002:adf:e74a:: with SMTP id c10mr5124703wrn.109.1588703794305; Tue, 05 May 2020 11:36:34 -0700 (PDT) Received: from [192.168.0.12] (cpc87281-slou4-2-0-cust47.17-4.cable.virginm.net. [92.236.12.48]) by smtp.gmail.com with ESMTPSA id z18sm4432147wrw.41.2020.05.05.11.36.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 May 2020 11:36:33 -0700 (PDT) Subject: =?UTF-8?Q?Re=3a_bug=2341001=3a_mkdir=3a_cannot_create_directory_?= =?UTF-8?B?4oCYdGVzdOKAmTogRmlsZSBleGlzdHM=?= To: Bob Proulx References: <3e663b56-7771-20c6-45aa-c709a7ee7296@redhat.com> <6f605632-0314-cb5d-d722-599d3e578e80@jguk.org> <232f6665-7edd-842c-ac9d-4fd2d6d86368@cs.ucla.edu> <48d4fbd5-3e57-00b3-9a3e-3f0795fa743f@cs.ucla.edu> <72ead2e2-85e5-723f-ecc8-63bf7d610c57@jguk.org> <9616f039-8109-ec1b-bb0a-9d229c8d30e5@cs.ucla.edu> <4752255f-d934-fa9e-ddfc-3a9983126746@cs.ucla.edu> <20200504123734454980598@bob.proulx.com> From: Jonny Grant Message-ID: <450f0b39-e51c-a1a5-6068-ed53883a2225@jguk.org> Date: Tue, 5 May 2020 19:36:32 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200504123734454980598@bob.proulx.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41001 Cc: 41001@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 04/05/2020 20:32, Bob Proulx wrote: > Jonny Grant wrote: >> Paul Eggert wrote: >>> Jonny Grant wrote: >>>> Is a more accurate strerror considered unreliable? >>>> >>>> Current: >>>> mkdir: cannot create directory ‘test’: File exists >>>> >>>> Proposed: >>>> mkdir: cannot create directory ‘test’: Is a directory >>> >>> I don't understand this comment. As I understand it you're proposing a change to >>> the mkdir command not a change to the strerror library function, and the change >>> you're proposing would introduce a race condition to the mkdir command. >> >> As the mkdir error returned to the shell is the same, I don't feel the >> difference between the words "File exists" and "Is a directory" on the >> terminal can be considered a race condition. > > I read the message thread carefully and the proposal was to add an > additional non-atomic stat(2) call to the logic. That sets up the > race condition. > > The difference in the words of the error string is not the race > condition. The race condition is created when trying to stat(2) the > file to see why it failed. That can only be done as a separate > action. That cannot be an atomic operation. That can only create a > race condition. > > For the low level utilities it is almost always a bad idea to layer in > additional system calls that are not otherwise there. Doing so almost > always creates additional bugs. And then there will be new bug > reports about those problems. And those will be completely valid. > > Try this experiment on your own. > > /tmp$ strace -e trace=mkdir mkdir foodir1 > mkdir("foodir1", 0777) = 0 > +++ exited with 0 +++ > > /tmp$ strace -e trace=mkdir mkdir foodir1 > mkdir("foodir1", 0777) = -1 EEXIST (File exists) > mkdir: cannot create directory ‘foodir1’: File exists > +++ exited with 1 +++ > > The first mkdir("foodir1", 0777) call succeeded. The second > mkdir("foodir1", 0777) call fail, returned -1, set errno = EEXIST, > EEXIST is the error number for "File exists". > > Note that this output line: > > mkdir("foodir1", 0777) = -1 EEXIST (File exists) > > That line was entirely reported by the 'strace' command and is not any > code related to the Coreutils mkdir command. The strace command > reported the same "File exists" message as mkdir did later, due to the > EEXIST error code. > > Let's try the same experiment with a file. And also with a pipe and a > character device too. > > /tmp$ touch file1 > > /tmp$ strace -e trace=mkdir mkdir file1 > mkdir("file1", 0777) = -1 EEXIST (File exists) > mkdir: cannot create directory ‘file1’: File exists > +++ exited with 1 +++ > > /tmp$ mkfifo fifo1 > > strace -e trace=mkdir mkdir fifo1 > mkdir("fifo1", 0777) = -1 EEXIST (File exists) > mkdir: cannot create directory ‘fifo1’: File exists > +++ exited with 1 +++ > > /tmp$ sudo mknod char1 c 5 0 > > /tmp$ strace -e trace=mkdir mkdir char1 > mkdir("char1", 0777) = -1 EEXIST (File exists) > mkdir: cannot create directory ‘char1’: File exists > +++ exited with 1 +++ > > And so we see that the kernel is returning the same EEXIST error code > for *all* cases where a file previously exists. And it is correct > because all of those are files. Because directories are files, pipes > are files, and files are files. Everything is a file. Therefore > EEXIST is a correct error message. > > In order to correctly change the message being reported the change > should be made in the kernel so that the kernel, which has the > information at that time atomically, could report an error providing > more detail than simply EEXIST. > > You have proposed that mkdir add a stat(2) system call to extract this > additional information. > >> as it's easy enough to call stat() like other package maintainers >> do, as you can see in binutils. > > *That* stat() addition creates the race condition. Adding a stat() > call cannot be done atomically. > > It would need to be done either before the mkdir(), after the mkdir(), > or both before and after. Let's see how that can go wrong. Let's say > we stat(), does not exist, we continue with mkdir(), fails with EEXIST > because another process got there first. So then we stat() again and > by that time the other process has already finished processing and > removed the directory again. A system call trace would look like > this. > > lstat("foodir1", 0x7ffcafc12800) = -1 ENOENT (No such file or directory) > mkdir("foodir1", 0777) = -1 EEXIST (File exists) > lstat("foodir1", 0x7ffcafc12800) = -1 ENOENT (No such file or directory) > > Okay. That's confusing. The only value in hand being EEXIST then > that is the error to be reported. If this were repeated many times > then sometimes we would catch it as an actual directory. > > lstat("foodir1", 0x7ffcafc12800) = -1 ENOENT (No such file or directory) > mkdir("foodir1", 0777) = -1 EEXIST (File exists) > lstat("foodir1", {st_mode=S_IFDIR|0775, st_size=40, ...}) = 0 > > In that case the proposal is to report it as EISDIR. If we were to > set up two processes coordinating using a directory as a semaphore and > printing out the errors then we would see a stream of output that is > sometimes the creation of the directory, sometimes the failure since a > directory already exists, and sometimes a failure because it is a > file. Race condition. That would be extremely confusing! I assure > you the valid bug reports would be swift and correctly merciless! > > And there is another possibility that is also bad too. We stat(), > does not exist, we continue with mkdir(), fails with EEXIST because > another process got there first creating it as a file. So then we > stat() again and by that time the other process has removed the file > and replaced it with a fifo device node. > > lstat("file1", 0x7ffdedf9aca0) = -1 ENOENT (No such file or directory) > mkdir("file1", 0777) = -1 EEXIST (File exists) > lstat("fifo1", {st_mode=S_IFIFO|0664, st_size=0, ...}) = 0 > > At that point the reason the mkdir actually failed was that it was a > file but the second stat() would have a report that it was a fifo > device which would be incorrect. Race condition. > > For the low level utilities it is almost always best to remain close > to the kernel and report the actual error reported by the kernel. > Constructing a layer in the low level utilities is almost always a bad > idea. > > However in your own shell scripts if you wish to construct exactly > this same layer that you are proposing then that is your prerogative. > But it would open your program up to valid bug reports for when the > race condition tripped one of the problem cases. > >> You're right, there will be a race condition where two processes are both >> creating and deleting the same files. Any software which is creating and >> deleting the same directories in parallel will encounter a multitude of >> errors - all bets are off. > > I am glad that you agree. That is exactly why adding non-atomic > operations to the low level utilities creating those race coditions is > a bad idea. > >>> A better fix would be to change the mkdir system call so that it sets errno to >>> EISDIR in this situation. This would fix not only the mkdir utility, but also >>> lots of other programs; and it wouldn't introduce a race condition. So if you're >>> interested in getting the problem fixed, I suggest that you propose such a >>> change to the Linux kernel developers. >> >> Yes, if Linux kernel developers would deviate from POSIX. I emailed >> linux-ext4@vger.kernel.org the lines of code to change. > > I am glad to see that you are following up in the right place. That > place being in the kernel. It can't be addressed correctly in user space. > >> I'm not confident it will get in, even harder to get into POSIX I expect. >> >> ext4_match() is what would need to be updated to check if an entry is a >> directory >> >> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/fs/ext4/namei.c > > ext4? But what if I am using xfs? Does this then behave differently > on ext4 versus ext3 versus xfs versus nfs4 versus... Well... You get > the idea. > > Sometimes the only way to win is not to play. Is the current EEXIST > really so bad that we would create additional problems just to avoid > it? Simplest is almost always best. > > Bob > Thank you for your reply, and going through it all. yes, I only asked Linux kernel ext4 team, as it is one place to ask the question, and judge the response. They also don't want to make any change. We're stuck with all these old interfaces. Unless someone wants to come up with mkdir2() and get it into POSIX. Maybe a simple localised string is better in your mkdir tool? After-all the man page and POSIX gives the exact meaning of EEXIST in this context? "pathname already exists" The output is only incorrect because it defaults to system localised strerror(EEXIST) So with this change, it would be: mkdir: cannot create directory ‘test’: pathname already exists Cheers, Jonny From debbugs-submit-bounces@debbugs.gnu.org Tue May 05 15:58:12 2020 Received: (at 41001) by debbugs.gnu.org; 5 May 2020 19:58:12 +0000 Received: from localhost ([127.0.0.1]:37631 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jW3hk-0007dj-Eg for submit@debbugs.gnu.org; Tue, 05 May 2020 15:58:12 -0400 Received: from us-smtp-1.mimecast.com ([205.139.110.61]:58191 helo=us-smtp-delivery-1.mimecast.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jW3hi-0007db-7h for 41001@debbugs.gnu.org; Tue, 05 May 2020 15:58:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1588708689; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=od3UJEW4yGBVdBhvD1E2JncvboxaztWMmMgyZG5jyys=; b=Czv8lEXABqJfF1Mq1/CpnHiYGyPy+vtUmFaH2+gt8brQPvbC7szn1ocN/SXClAU1bVXgrU unR7nVW9FpubmHWRRtA4SxayH1bMvJwMIRxlnNlTvS7K9pMrHt42wDkm+unV3B/yRxcUCv UqqbsTD+ScS+hfpiWlNq4IpO98vePTQ= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-184-_ZqaibeQPn6u7oifnEy8BA-1; Tue, 05 May 2020 15:58:04 -0400 X-MC-Unique: _ZqaibeQPn6u7oifnEy8BA-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 89C9746B; Tue, 5 May 2020 19:58:03 +0000 (UTC) Received: from [10.3.114.73] (ovpn-114-73.phx2.redhat.com [10.3.114.73]) by smtp.corp.redhat.com (Postfix) with ESMTPS id EB6635C241; Tue, 5 May 2020 19:58:02 +0000 (UTC) Subject: =?UTF-8?Q?Re=3a_bug=2341001=3a_mkdir=3a_cannot_create_directory_?= =?UTF-8?B?4oCYdGVzdOKAmTogRmlsZSBleGlzdHM=?= To: Jonny Grant , Bob Proulx References: <3e663b56-7771-20c6-45aa-c709a7ee7296@redhat.com> <6f605632-0314-cb5d-d722-599d3e578e80@jguk.org> <232f6665-7edd-842c-ac9d-4fd2d6d86368@cs.ucla.edu> <48d4fbd5-3e57-00b3-9a3e-3f0795fa743f@cs.ucla.edu> <72ead2e2-85e5-723f-ecc8-63bf7d610c57@jguk.org> <9616f039-8109-ec1b-bb0a-9d229c8d30e5@cs.ucla.edu> <4752255f-d934-fa9e-ddfc-3a9983126746@cs.ucla.edu> <20200504123734454980598@bob.proulx.com> <450f0b39-e51c-a1a5-6068-ed53883a2225@jguk.org> From: Eric Blake Organization: Red Hat, Inc. Message-ID: <8c9587f6-946d-64b0-467c-cf65f16e8ae1@redhat.com> Date: Tue, 5 May 2020 14:58:02 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <450f0b39-e51c-a1a5-6068-ed53883a2225@jguk.org> Content-Language: en-US X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41001 Cc: 41001@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 5/5/20 1:36 PM, Jonny Grant wrote: >> >> Okay.=C2=A0 That's confusing.=C2=A0 The only value in hand being EEXIST = then >> that is the error to be reported.=C2=A0 If this were repeated many times >> then sometimes we would catch it as an actual directory. >> >> =C2=A0=C2=A0 lstat("foodir1", 0x7ffcafc12800)=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 =3D -1 ENOENT (No such file or=20 >> directory) >> =C2=A0=C2=A0 mkdir("foodir1", 0777)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D -1 EEXIST = (File exists) >> =C2=A0=C2=A0 lstat("foodir1", {st_mode=3DS_IFDIR|0775, st_size=3D40, ...= }) =3D 0 >> >> In that case the proposal is to report it as EISDIR. >=20 > yes, I only asked Linux kernel ext4 team, as it is one place to ask the= =20 > question, and judge the response. They also don't want to make any=20 > change. We're stuck with all these old interfaces. Unless someone wants= =20 > to come up with mkdir2() and get it into POSIX. We already have mkdirat() specified by POSIX. It would be easier to add=20 a new O_ flag that tells mkdirat() to give a different errno failure=20 than to add a completely new interface. But emulating that new flag on=20 older kernels that don't natively support it will be back at the same=20 non-atomic racy situation we are in now. >=20 > Maybe a simple localised string is better in your mkdir tool? After-all= =20 > the man page and POSIX gives the exact meaning of EEXIST in this context? >=20 > "pathname already exists" If you can convince glibc to change the contents of their=20 strerror(EEXIST) along those lines, then go for it. But they would=20 probably tell you that the GNU Coding Standards frown on using=20 "pathname" instead of "filename" (per GCS, "path" should be reserved for=20 colon-separated lists such as $PATH - which is a different definition=20 than POSIX has where "path" is merely a concatenation of "filenames"=20 using '/', so it's a tough sell. >=20 >=20 > The output is only incorrect because it defaults to system localised=20 > strerror(EEXIST) >=20 > So with this change, it would be: >=20 > mkdir: cannot create directory =E2=80=98test=E2=80=99: pathname already e= xists Giving different output than strerror() will confuse users; it's better=20 to make the change in glibc for ALL clients of strerror(EEXIST) rather=20 than just this one client. --=20 Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org From debbugs-submit-bounces@debbugs.gnu.org Tue May 05 23:12:33 2020 Received: (at 41001) by debbugs.gnu.org; 6 May 2020 03:12:33 +0000 Received: from localhost ([127.0.0.1]:38038 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jWAU3-0003je-LN for submit@debbugs.gnu.org; Tue, 05 May 2020 23:12:33 -0400 Received: from sonic302-20.consmr.mail.ne1.yahoo.com ([66.163.186.146]:44902) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jWABn-0003HD-Ci for 41001@debbugs.gnu.org; Tue, 05 May 2020 22:53:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1588733612; bh=+8kG4MfayacvFPDOYfQRs/2pnSnYIWVJWbJuokDeCXQ=; h=Date:From:To:In-Reply-To:References:Subject:From:Subject; b=BWh0ox2+9OFzBh84nc1PkwYYhJH7ddXxIdJFoAsG3OI2OTJ1ZZDSXL1+l/FGPUyMyKM1MdAe10OZpi61AF5frjiN1L7QvnLzTD7QHjkPAuezO5CyniT4SWr5gLHYsxP1vWeuA6/1Ui9/ARAhTog+9N14802yAaoaCiTA6wSL7nA1Jp2+B1H7Jw81I6Tk6i/a/RZbK1N+K29A04q61onMGG1URBoDj/xV+BO60aXcNule2Q2M0qnBH89TFt87WF/me9Ut5PV92cWZTk3lFLQloOCqhE9EhxPYjKAX+wyFBZhlQkiesN7XJDA7JnuKPVwD8hGuHkMIdsKK9EqLrKUQVQ== X-YMail-OSG: 5aRUJxcVM1lwjQS3LMDy10U.QcrR0DSMbYF_hcICh.VXVroqibUoyBzzviKfq8n B0Z4XWsCEEdP8P8SQsFXsQrQZUtuPAlfi1i3s7ElW69JwMFkWwuerJvApkfZ.GQIHYzv9uohplBL sx92OltNhNaSnUwV4JN9kK5UmDh2tJR22sTtC_j4l_M9K4OHPUsuXBIAd.M_35QwhamQxPPEDKqa q9hrVN9ZBvdZCJiEqN.KivA5E2CGOYj4Rm33XL.cU8mD5o_zCviZ0hObQouGHaGWcCT1iQA0X6Sd pACX0QOHG6YKDanAgqWPI9opx6kSXOdQ0pwFW6ETfSHkj5_orjSHvHnSKuh5Ct11Xtup5j.z8RL5 WhssXt7L5IzJ79NdSEaOZoQN2qrScs9bP73RVknYUxQEKk_uXb31shR5nsv3Op9y6W2TSLkvknqY Mfr5Ljfhx4kusEsBaYkF8NcXdjAUtCY5tDPTb1goqPZ_wqY2KXdnNTq0LhOWq7uhPi6EIDd.fb3J a1.GQEmTH65nznLCxv4n_.n97AjPrAZSpsTk_3NmXg6NhKkyoz6eqjKHXHja4bY2KzM3mtEHhvQS vrW3gDzLkcYgHGDosr5fvVvieNjiBWSO_1_3B6.9irOuKrLanCXhnOdk5I6RqfxzO1ogy7Oa3L9B zhHYowd7Y9wNcr562gz_MQ6SoEnXGaLfhufuGxoHTyL7IeeVxWqC0Vwc.zywUd2YyfE_YnYet6EN wjqP4gnvYcNzDNJDynsovMjY5Y7_ZnK1NQloXFVCEmEkcAno_CXZHm5otktrwYNkHI6Jz8C5o9X_ 0K5IzXN6PU.5xKcqtxiUeXZ0brsvKGolKRYQsR9PlA2zWl5JRK0KDbmsIOdO_Q.t7c6bRV5vbRaA gzvwR.xWzXy22wighPwAkBEKC2P_wd5_G747WCLHG6UqyldKelemi97O0MemmXxUOkU2sX946A_y JTJWYjmkoviJmuQkTUIibH41TzGPFV8spXO9HEtEk5waU8kum7cSE0fQiqSUn0oY_1rE7ggcFWla _t.1UEUWol2QiVPLuyQLLer3l7EHFZgA6DFijSMboSjvnty_3YlmjUbJIZYwbPSDwfxJuOeMntpi 9WVuDFv.Jc2Z1ruuscS4rvMXKxV4irZF3ZwaYvtU.3B_dmdYf1iBkCq2UNnw7fZGTx25tc4TQKSC r4nV4JHW1ogy.4QVgwOxsB2ehEvLf5l38yhsQeQ6Ml1f5LTzOgqsDxYmSFVvElr0ZdbkKiQv66re b_uNTSrRnRDe4_gTlwz1rf_ked62f2qqDHthRPAH8tXbI_slLDCP4W_c- Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.ne1.yahoo.com with HTTP; Wed, 6 May 2020 02:53:32 +0000 Date: Wed, 6 May 2020 02:53:29 +0000 (UTC) From: taehwan jeoung To: 41001@debbugs.gnu.org, Jonny Grant Message-ID: <624099291.1982538.1588733609693@mail.yahoo.com> In-Reply-To: <40df8619-2aec-9660-14f2-b674fc0e6d14@jguk.org> References: <40df8619-2aec-9660-14f2-b674fc0e6d14@jguk.org> Subject: =?UTF-8?Q?Re:_bug#41001:_mkdir:_cannot_cre?= =?UTF-8?Q?ate_directory_=E2=80=98test=E2=80=99:_File_exists?= MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1982537_522128445.1588733609692" X-Mailer: WebService/1.1.15756 YMailNorrin Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.1 Safari/605.1.15 Content-Length: 4512 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41001 X-Mailman-Approved-At: Tue, 05 May 2020 23:12:31 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) ------=_Part_1982537_522128445.1588733609692 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Stupid.mkdir -r test.mkdir test.Read your gnu manual to solve your digital= illiteracy. 2020=EB=85=84 5=EC=9B=94 2=EC=9D=BC =ED=86=A0=EC=9A=94=EC=9D=BC =EC=98= =A4=EC=A0=84 12=EC=8B=9C 17=EB=B6=84 45=EC=B4=88 GMT+9, Jonny Grant =EC=9E=91=EC=84=B1: =20 =20 Hello! Can this error message be clarified? The directory already exists, it is=20 not a file. lib/mkdir-p.c:200 contains this line of code that triggers below:- error (0, mkdir_errno, _("cannot create directory %s"), quote (dir)); As it's easy enough to know that the reason mkdir fails is because=20 'test' a directory that already exists. Easy enough to check with stat() and S_ISDIR(sb.st_mode) Can this be changed? Maybe I can make a patch for it. Jonny $ mkdir test $ mkdir test mkdir: cannot create directory =E2=80=98test=E2=80=99: File exists $ mkdir --version mkdir (GNU coreutils) 8.28 Copyright (C) 2017 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later=20 . This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Written by David MacKenzie. $ =20 ------=_Part_1982537_522128445.1588733609692 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Stupid.
mkdir -r test.
mkdir test.
Read your g= nu manual to solve your digital illiteracy.

=20
=20
2020=EB=85=84 5=EC=9B=94 2=EC=9D=BC =ED=86=A0=EC=9A=94= =EC=9D=BC =EC=98=A4=EC=A0=84 12=EC=8B=9C 17=EB=B6=84 45=EC=B4=88 GMT+9, Jon= ny Grant <jg@jguk.org> =EC=9E=91=EC=84=B1:


Hello!

=
Can this error message be clarified? The directory a= lready exists, it is
not a file.

lib/mkdir-p.c:200 contains this line = of code that triggers below:-

error (0, mkdir_errno, _("cannot create directory %s"), quote (dir= ));

As it's easy enoug= h to know that the reason mkdir fails is because
'test' a directory that already exists.

Easy enough to check with stat() and S_ISDIR(sb.st_mode)=

Can this be changed? = Maybe I can make a patch for it.
Jonny
<= div dir=3D"ltr">


<= /div>
$ mkdir test
$ mkdir test
mkdir: cannot create directory =E2=80=98test=E2=80= =99: File exists
$ mkdir --version
mkdir (GNU coreutils) 8.28
Copyright = (C) 2017 Free Software Foundation, Inc.
License G= PLv3+: GNU GPL version 3 or later
This is free software: you ar= e free to change and redistribute it.
There is NO= WARRANTY, to the extent permitted by law.

Written by David MacKenzie.
= $



------=_Part_1982537_522128445.1588733609692-- From debbugs-submit-bounces@debbugs.gnu.org Wed May 06 00:35:00 2020 Received: (at 41001) by debbugs.gnu.org; 6 May 2020 04:35:00 +0000 Received: from localhost ([127.0.0.1]:38143 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jWBls-0005rG-5Y for submit@debbugs.gnu.org; Wed, 06 May 2020 00:35:00 -0400 Received: from havoc.proulx.com ([96.88.95.61]:54720) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jWBlq-0005r3-BJ for 41001@debbugs.gnu.org; Wed, 06 May 2020 00:34:58 -0400 Received: from joseki.proulx.com (localhost [127.0.0.1]) by havoc.proulx.com (Postfix) with ESMTP id C259C62B; Tue, 5 May 2020 22:34:52 -0600 (MDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proulx.com; s=dkim2048; t=1588739692; bh=sHZtC1fNqy6G4/lqh46YaLr1l/66VHgwIt5hTcx36QA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=YHikq61638euv5V2rHHrJUVjo39ba/lZOjbgtJyDuwD6MpjPJDnduP/LexwAYD5+G jVG9kBVz2BbG5Myt7Us8YM1aSgTFCYyPH/NGbPImdXFl4rlvAIw3eHJ4Ueb1f8mLeV jkKOb7b/QmnL7/D29nh13ssRcb+jBhLnjTIfoBw8i2gCBUn0Fxi0mO4t81cc4Hb9lW hSg1XnqBvlqjlZ6zg77NFZL+1dKBUUY4lg5/qT4a4xqtufldQPjSRKWi7OVKrlamq3 6EiKAIJ77ohl5dC5z3BAke5DsyAPnLD0biGjTKBPstWvFtQ1aCWEVRcZomCa7G8lbz 5rQaNaTpvxdyQ== Received: from hysteria.proulx.com (hysteria.proulx.com [192.168.230.119]) by joseki.proulx.com (Postfix) with ESMTP id 91DA721150; Tue, 5 May 2020 22:34:52 -0600 (MDT) Received: by hysteria.proulx.com (Postfix, from userid 1000) id 6A2132DC8C; Tue, 5 May 2020 22:34:52 -0600 (MDT) Date: Tue, 5 May 2020 22:34:52 -0600 From: Bob Proulx To: taehwan jeoung , Jonny Grant Subject: Re: bug#41001: mkdir: cannot =?utf-8?Q?cre?= =?utf-8?B?YXRlIGRpcmVjdG9yeSDigJh0ZXN04oCZOg==?= File exists Message-ID: <20200505221131312814176@bob.proulx.com> References: <40df8619-2aec-9660-14f2-b674fc0e6d14@jguk.org> <624099291.1982538.1588733609693@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <624099291.1982538.1588733609693@mail.yahoo.com> X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41001 Cc: 41001@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) taehwan jeoung wrote: > Can this error message be clarified? The directory already exists, it is > not a file. That is incorrect. Directories are files. FIFOs are files. Device nodes are files. Symlinks are files. Network sockets are files. They are all files. Therefore it is not incorrect to say that a file already exists. Directories are files. We have all agreed that if a better error message were provided then that would be an improvement. We agree with you. We would do it if it were within the power of mkdir(1) to do it. But it isn't. Therefore we can't. > lib/mkdir-p.c:200 contains this line of code that triggers below:- > > error (0, mkdir_errno, _("cannot create directory %s"), quote (dir)); > > As it's easy enough to know that the reason mkdir fails is because > 'test' a directory that already exists. That is also incorrect. Since that information is not provided at the time of the action it can only be inferred by implication later. But at the time of the failure return it cannot be known unless the kernel provides that information. Later in time things might have changed. > Easy enough to check with stat() and S_ISDIR(sb.st_mode) Incorrect. Checking *later* with stat() does not provide the reason that the earlier mkdir(2) failed. It provides a guess of something that might be the reason. Maybe. Or it maybe not. Things may have changed later in time and the guess made later might not be the correct reason. Reporting that as if it were would be a worse bug. That checking later in time after the mkdir has failed is what introduces the race condition that we have been talking about. Please do not ignore that critically important point. > Can this be changed? Maybe I can make a patch for it. Sigh. Ignoring the reasons why this is a bad idea are not helpful. Bob From debbugs-submit-bounces@debbugs.gnu.org Thu May 07 07:30:08 2020 Received: (at 41001) by debbugs.gnu.org; 7 May 2020 11:30:08 +0000 Received: from localhost ([127.0.0.1]:42247 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jWej9-0001s2-PL for submit@debbugs.gnu.org; Thu, 07 May 2020 07:30:08 -0400 Received: from mail-wr1-f67.google.com ([209.85.221.67]:35312) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jWej7-0001lK-Ri for 41001@debbugs.gnu.org; Thu, 07 May 2020 07:30:06 -0400 Received: by mail-wr1-f67.google.com with SMTP id j5so5946405wrq.2 for <41001@debbugs.gnu.org>; Thu, 07 May 2020 04:30:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jguk.org; s=google; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=bxINEavfQAfdPRnQdG66XNxHWllSYFERefz1Ps8tjnk=; b=DouVkYN8pOL6dvuob40azvjqKemwRpjB5o4dwHLQ66VThgm72FsQ4EYQU+v6/UONWk TuEA0TK1y63xjZ7hQJpYuXLkOp5Mv9C0LyQv7MyCHeowfqbylwwd+pxD4lkyENzOGOVe ly8tn1ql/yizTyP1ymXzHtDleGDs9scAHaGf692KYI9Y4buCl+oKc4YYLoXDAm1adu5m W8egriRyWitNxJ3yPQTllbHRrOL2T11OuWRGwjVBaIOogSTkYoI5nJHONFYM4N5EhHp7 t5Djeh6d2roq23jzxwIq54GKWCG1sHIJJfRoMBd79yfSpmmuR3gpUKd1aRB2tpJGPNGg vVQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=bxINEavfQAfdPRnQdG66XNxHWllSYFERefz1Ps8tjnk=; b=JkK2nOlw1U9iWhJGf6vI2YDzrpCIbWLFz/+Tn9jJXAkR3C7nrV43ozGvN3fSKmEHYe JE2KD5YpBL2uzYqrAUftklJbBHQ4e+1n8iWM9AT9/uy7n+Em8MLHLtujc953dU99Be67 7BYWorvXcJCMVsngliO6YS/wwVYc6PejsF8iZIs278n26NKsFQb97DoPd33OKJs//Kb8 O66JUTSFrvrqLG9vJV7kFJ9LvqO6jH1bzh57CbfDoJGZ5JXXo0R/r+A1ponE7oWpSsPX vpUtSPsbty8zSanuHh//LCkXJZmnlmwd4pcd+3IcnVMfwgImRajMPs4haF70VWUsytXQ oT7w== X-Gm-Message-State: AGi0PuZkZC8kn6ouGrRrM6NX6hGl0IJTGkZv8Rd+8kOBKuNKAPb5IRpu d9RO69OUxVgG7OiUOqVcXiyINHNSMe0= X-Google-Smtp-Source: APiQypKhjT5L9SubS0aV3CmcfC7dq4z2njfw6Zqick3cqW5xTHF0BLgoG1bidsTujZd0mZP2wTjXpA== X-Received: by 2002:a05:6000:146:: with SMTP id r6mr15903108wrx.9.1588850999629; Thu, 07 May 2020 04:29:59 -0700 (PDT) Received: from [192.168.0.12] (cpc87281-slou4-2-0-cust47.17-4.cable.virginm.net. [92.236.12.48]) by smtp.gmail.com with ESMTPSA id g69sm8254562wmg.17.2020.05.07.04.29.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 May 2020 04:29:58 -0700 (PDT) From: Jonny Grant Subject: =?UTF-8?Q?Re=3a_bug=2341001=3a_mkdir=3a_cannot_create_directory_?= =?UTF-8?B?4oCYdGVzdOKAmTogRmlsZSBleGlzdHM=?= To: Eric Blake , Bob Proulx References: <3e663b56-7771-20c6-45aa-c709a7ee7296@redhat.com> <6f605632-0314-cb5d-d722-599d3e578e80@jguk.org> <232f6665-7edd-842c-ac9d-4fd2d6d86368@cs.ucla.edu> <48d4fbd5-3e57-00b3-9a3e-3f0795fa743f@cs.ucla.edu> <72ead2e2-85e5-723f-ecc8-63bf7d610c57@jguk.org> <9616f039-8109-ec1b-bb0a-9d229c8d30e5@cs.ucla.edu> <4752255f-d934-fa9e-ddfc-3a9983126746@cs.ucla.edu> <20200504123734454980598@bob.proulx.com> <450f0b39-e51c-a1a5-6068-ed53883a2225@jguk.org> <8c9587f6-946d-64b0-467c-cf65f16e8ae1@redhat.com> Message-ID: Date: Thu, 7 May 2020 12:29:58 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <8c9587f6-946d-64b0-467c-cf65f16e8ae1@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41001 Cc: 41001@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hi Eric On 05/05/2020 20:58, Eric Blake wrote: > On 5/5/20 1:36 PM, Jonny Grant wrote: > >>> >>> Okay.  That's confusing.  The only value in hand being EEXIST then >>> that is the error to be reported.  If this were repeated many times >>> then sometimes we would catch it as an actual directory. >>> >>>    lstat("foodir1", 0x7ffcafc12800)       = -1 ENOENT (No such file >>> or directory) >>>    mkdir("foodir1", 0777)                 = -1 EEXIST (File exists) >>>    lstat("foodir1", {st_mode=S_IFDIR|0775, st_size=40, ...}) = 0 >>> >>> In that case the proposal is to report it as EISDIR. > >> >> yes, I only asked Linux kernel ext4 team, as it is one place to ask >> the question, and judge the response. They also don't want to make any >> change. We're stuck with all these old interfaces. Unless someone >> wants to come up with mkdir2() and get it into POSIX. > > We already have mkdirat() specified by POSIX.  It would be easier to add > a new O_ flag that tells mkdirat() to give a different errno failure > than to add a completely new interface.  But emulating that new flag on > older kernels that don't natively support it will be back at the same > non-atomic racy situation we are in now. Sounds good. Would that O_ flag work on the 'mode' ? in which case could be mkdir() too. >> >> Maybe a simple localised string is better in your mkdir tool? >> After-all the man page and POSIX gives the exact meaning of EEXIST in >> this context? >> >> "pathname already exists" > > If you can convince glibc to change the contents of their > strerror(EEXIST) along those lines, then go for it.  But they would > probably tell you that the GNU Coding Standards frown on using > "pathname" instead of "filename" (per GCS, "path" should be reserved for > colon-separated lists such as $PATH - which is a different definition > than POSIX has where "path" is merely a concatenation of "filenames" > using '/', so it's a tough sell. "name already exists" might work, or "Directory or file already exists". Although it's almost certainly impossible, they also won't want to change it for strerror(EEXIST) This comment is based on something Andreas Dilger suggested on the ext4 list: How about updating mkdir tool with this? if (EEXIST == errno) { errmsg = _("name already exists"); } >> The output is only incorrect because it defaults to system localised >> strerror(EEXIST) >> >> So with this change, it would be: >> >> mkdir: cannot create directory ‘test’: pathname already exists > > Giving different output than strerror() will confuse users; it's better > to make the change in glibc for ALL clients of strerror(EEXIST) rather > than just this one client. I doubt glibc would ever agree to change strerror(EEXIST). I imagine it all gets beaurocratic, and they might require POSIX make the update to the spec first? Cheers, Jonny From debbugs-submit-bounces@debbugs.gnu.org Thu May 07 22:06:14 2020 Received: (at 41001) by debbugs.gnu.org; 8 May 2020 02:06:14 +0000 Received: from localhost ([127.0.0.1]:44257 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jWsP0-0007F3-1O for submit@debbugs.gnu.org; Thu, 07 May 2020 22:06:14 -0400 Received: from us-smtp-2.mimecast.com ([207.211.31.81]:46156 helo=us-smtp-delivery-1.mimecast.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jWsOv-0007Es-If for 41001@debbugs.gnu.org; Thu, 07 May 2020 22:06:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1588903568; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=XZkjYYHjvEskre2FCjRUyupv7nFiZ/XvglsfOqNdwfY=; b=Gj6/1CmeQXxJjFUyWholYnXVwnG1sWxCN6B3HYVL4C2VazSSIIgZS6tCfNm8Lx40PepIou fL7vOWfAdR8T9nUnM0v7isTUrmfslkY/YGxlHtxvI6+DJmOuHYUysR3eOTelaR2o50R7s1 5W1IqSmnTzvYQ3JXERzM6b67sbGi31Q= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-439-yBCPXQjGM_OT3TJRbQrxeg-1; Thu, 07 May 2020 22:06:04 -0400 X-MC-Unique: yBCPXQjGM_OT3TJRbQrxeg-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 19D4080B713; Fri, 8 May 2020 02:06:03 +0000 (UTC) Received: from [10.3.114.73] (ovpn-114-73.phx2.redhat.com [10.3.114.73]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7A80260CD0; Fri, 8 May 2020 02:06:02 +0000 (UTC) Subject: =?UTF-8?Q?Re=3a_bug=2341001=3a_mkdir=3a_cannot_create_directory_?= =?UTF-8?B?4oCYdGVzdOKAmTogRmlsZSBleGlzdHM=?= To: Jonny Grant , Bob Proulx References: <3e663b56-7771-20c6-45aa-c709a7ee7296@redhat.com> <6f605632-0314-cb5d-d722-599d3e578e80@jguk.org> <232f6665-7edd-842c-ac9d-4fd2d6d86368@cs.ucla.edu> <48d4fbd5-3e57-00b3-9a3e-3f0795fa743f@cs.ucla.edu> <72ead2e2-85e5-723f-ecc8-63bf7d610c57@jguk.org> <9616f039-8109-ec1b-bb0a-9d229c8d30e5@cs.ucla.edu> <4752255f-d934-fa9e-ddfc-3a9983126746@cs.ucla.edu> <20200504123734454980598@bob.proulx.com> <450f0b39-e51c-a1a5-6068-ed53883a2225@jguk.org> <8c9587f6-946d-64b0-467c-cf65f16e8ae1@redhat.com> From: Eric Blake Organization: Red Hat, Inc. Message-ID: Date: Thu, 7 May 2020 21:06:01 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41001 Cc: 41001@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 5/7/20 6:29 AM, Jonny Grant wrote: >> >> We already have mkdirat() specified by POSIX.=C2=A0 It would be easier t= o=20 >> add a new O_ flag that tells mkdirat() to give a different errno=20 >> failure than to add a completely new interface.=C2=A0 But emulating that= =20 >> new flag on older kernels that don't natively support it will be back=20 >> at the same non-atomic racy situation we are in now. >=20 > Sounds good. >=20 > Would that O_ flag work on the 'mode' ? in which case could be mkdir() to= o. Bummer. I forgot that mkdirat() was one of the interfaces that lacks a=20 separate flags parameter (I was thinking more about openat). But ultimately, whether the kernel adds a mkdirat4(dirfd, name, mode,=20 flags), or merely adds flags that can be OR'd in with mode, is up to the=20 kernel folks. You'll have to convince someone in the kernel that an=20 extension to the existing interface is worthwhile. Ruminating on what=20 that extension might look like here on the coreutils list won't get it=20 any closer to actually being implemented. (My personal wish: I would love a variation of mkdir that returns an=20 open fd on the just-created directory on success in a single syscall,=20 instead of the current practice of having to pair mkdir()/open() -=20 something that is also doable if you have a flags parameter to opt-in to=20 that new behavior.) >> Giving different output than strerror() will confuse users; it's=20 >> better to make the change in glibc for ALL clients of strerror(EEXIST)= =20 >> rather than just this one client. >=20 > I doubt glibc would ever agree to change strerror(EEXIST). I imagine it= =20 > all gets beaurocratic, and they might require POSIX make the update to=20 > the spec first? POSIX does _not_ require that strerror(EEXIST) output "File exists", but=20 merely that it represent _some_ error message about a directory entry=20 already existing (most generically called a file, even when it is not a=20 regular file). I see no reason why glibc developers would be able to=20 use POSIX as a reason why they could not change their output table. But=20 you are also right that they might have other arguments about why=20 changing an output string is undesirable. But to find out, you'll have=20 to ask on the glibc list, not here. --=20 Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org From debbugs-submit-bounces@debbugs.gnu.org Sun May 10 15:07:53 2020 Received: (at 41001) by debbugs.gnu.org; 10 May 2020 19:07:53 +0000 Received: from localhost ([127.0.0.1]:50420 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jXrIn-0003z6-K0 for submit@debbugs.gnu.org; Sun, 10 May 2020 15:07:53 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:48786) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jXrIl-0003yq-HV for 41001@debbugs.gnu.org; Sun, 10 May 2020 15:07:52 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 6FF751600AF; Sun, 10 May 2020 12:07:44 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id JzOqPjjThEd6; Sun, 10 May 2020 12:07:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id BF7201600C7; Sun, 10 May 2020 12:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id PlefEeiT8rmO; Sun, 10 May 2020 12:07:43 -0700 (PDT) Received: from [192.168.1.9] (cpe-23-242-74-103.socal.res.rr.com [23.242.74.103]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 84B7C1600AF; Sun, 10 May 2020 12:07:43 -0700 (PDT) Subject: =?UTF-8?Q?Re=3a_bug=2341001=3a_mkdir=3a_cannot_create_directory_?= =?UTF-8?B?4oCYdGVzdOKAmTogRmlsZSBleGlzdHM=?= To: Eric Blake , Jonny Grant , Bob Proulx References: <3e663b56-7771-20c6-45aa-c709a7ee7296@redhat.com> <6f605632-0314-cb5d-d722-599d3e578e80@jguk.org> <232f6665-7edd-842c-ac9d-4fd2d6d86368@cs.ucla.edu> <48d4fbd5-3e57-00b3-9a3e-3f0795fa743f@cs.ucla.edu> <72ead2e2-85e5-723f-ecc8-63bf7d610c57@jguk.org> <9616f039-8109-ec1b-bb0a-9d229c8d30e5@cs.ucla.edu> <4752255f-d934-fa9e-ddfc-3a9983126746@cs.ucla.edu> <20200504123734454980598@bob.proulx.com> <450f0b39-e51c-a1a5-6068-ed53883a2225@jguk.org> <8c9587f6-946d-64b0-467c-cf65f16e8ae1@redhat.com> From: Paul Eggert Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkV5QWNtUUJFQURB QXlIMnhvVHU3cHBHNUQzYThGTVpFb243NGRDdmM0K3ExWEEySjJ0QnkycHdhVHFmCmhweHhk R0E5Smo1MFVKM1BENGJTVUVnTjh0TFowc2FuNDdsNVhUQUZMaTI0NTZjaVNsNW04c0thSGxH ZHQ5WG0KQUF0bVhxZVpWSVlYL1VGUzk2ZkR6ZjR4aEVtbS95N0xiWUVQUWRVZHh1NDd4QTVL aFRZcDVibHRGM1dZRHoxWQpnZDdneDA3QXV3cDdpdzdlTnZub0RUQWxLQWw4S1lEWnpiRE5D UUdFYnBZM2VmWkl2UGRlSStGV1FONFcra2doCnkrUDZhdTZQcklJaFlyYWV1YTdYRGRiMkxT MWVuM1NzbUUzUWpxZlJxSS9BMnVlOEpNd3N2WGUvV0szOEV6czYKeDc0aVRhcUkzQUZINmls QWhEcXBNbmQvbXNTRVNORnQ3NkRpTzFaS1FNcjlhbVZQa25qZlBtSklTcWRoZ0IxRApsRWR3 MzRzUk9mNlY4bVp3MHhmcVQ2UEtFNDZMY0ZlZnpzMGtiZzRHT1JmOHZqRzJTZjF0azVlVThN Qml5Ti9iClowM2JLTmpOWU1wT0REUVF3dVA4NGtZTGtYMndCeHhNQWhCeHdiRFZadWR6eERa SjFDMlZYdWpDT0pWeHEya2wKakJNOUVUWXVVR3FkNzVBVzJMWHJMdzYrTXVJc0hGQVlBZ1Jy NytLY3dEZ0JBZndoUEJZWDM0blNTaUhsbUxDKwpLYUhMZUNMRjVaSTJ2S20zSEVlQ1R0bE9n N3haRU9OZ3d6TCtmZEtvK0Q2U29DOFJSeEpLczhhM3NWZkk0dDZDCm5yUXp2SmJCbjZneGRn Q3U1aTI5SjFRQ1lyQ1l2cWwyVXlGUEFLK2RvOTkvMWpPWFQ0bTI4MzZqMXdBUkFRQUIKdENC UVlYVnNJRVZuWjJWeWRDQThaV2RuWlhKMFFHTnpMblZqYkdFdVpXUjFQb2tDUGdRVEFRSUFL QVVDVElCeQpaQUliQXdVSkVzd0RBQVlMQ1FnSEF3SUdGUWdDQ1FvTEJCWUNBd0VDSGdFQ0Y0 QUFDZ2tRN1pmcERtS3FmalJSCkd3LytJajAzZGhZZllsL2dYVlJpdXpWMWdHcmJIayt0bmZy SS9DN2ZBZW9GelE1dFZnVmluU2hhUGtabzBIVFAKZjE4eDZJREVkQWlPOE1xbzF5cDBDdEht ekdNQ0o1MG80R3JnZmpscjZnLyt2dEVPS2JobGVzek4yWHBKdnB3TQoyUWdHdm4vbGFUTFV1 OFBIOWFSV1RzN3FKSlpLS0tBYjRzeFljOTJGZWhQdTZGT0QwZERpeWhsREFxNGxPVjJtCmRC cHpRYmlvam9aelFMTVF3anBnQ1RLMjU3MmVLOUVPRVF5U1VUaFhyU0l6NkFTZW5wNE5ZVEZI czl0dUpRdlgKazlnWkRkUFNsM2JwKzQ3ZEd4bHhFV0xwQklNN3pJT053NGtzNGF6Z1Q4bnZE WnhBNUlaSHR2cUJsSkxCT2JZWQowTGU2MVdwMHkzVGxCRGgycWRLOGVZTDQyNlc0c2NFTVN1 aWc1Z2I4T0F0UWlCVzZrMnNHVXh4ZWl2OG92V3U4CllBWmdLSmZ1b1dJK3VSbk1FZGRydVk4 SnNvTTU0S2FLdlppa2tLczJiZzFuZHRMVnpIcEo2cUZaQzdRVmplSFUKaDYvQm1ndmRqV1Ba WUZUdE4rS0E5Q1dYM0dRS0tnTjN1dTk4OHl6bkQ3TG5COThUNEVVSDFIQS9HbmZCcU1WMQpn cHpUdlBjNHFWUWluQ21Ja0VGcDgzemwrRzVmQ2pKSjNXN2l2ekNuWW80S2hLTHBGVW05N29r VEtSMkxXM3haCnpFVzRjTFNXTzM4N01USzNDekRPeDVxZTZzNGE5MVp1Wk0vai9UUWRUTERh cU5uODNrQTRIcTQ4VUhYWXhjSWgKK05kOGsvM3c2bEZ1b0swd3JPRml5d2pMeCswdXI1am1t YmVjQkdIYzF4ZGhBRkc1QWcwRVRJQnlaQUVRQUthRgo2NzhUOXd5SDR3alRyVjFQejNjREVv U25WLzBaVXJPVDM3cDFkY0d5ai9JWHExeDY3MEhSVmFoQW1rMHNacFljCjI1UEY5RDVHUFlI RldsTmp1UFU5NnJEbmRYQjNoZWRtQlJoTGRDNGJBWGpJNERWK2JtZFZlK3EvSU1ubFpSYVYK bG05RWlNQ1ZBUjZ3MTNzUmV1N3FYa1c5cjNSd1kyQXpYc2twL3RBZTRCUktyMVptYnZpMm5i blE2ZXBFQzQycgpSYngwQjFFaGpiSVFaNUpIR2syNGlQVDdMZEJnbk5tb3M1d1lqendObGtN UUQ1VDBZZHpoazdKK1V4d0E1bTQ2Cm1PaFJEQzJyRlYvQTBnbTVUTHk4RFhqdi9Fc2M0Z1lu WWFpNlNRcW5VRVZoNUx1VjhZQ0pCbmlqcytUaXc3MXgKMWljbW42eEdJNDVFdWdKT2dlYyty THlwWWdwVnA0eDBISTVUODhxQlJZQ2t4SDNLZzhRbytFV05BOUE0TFJROQpEWDhuam9uYTBn ZjBzMDN0b2NLOGtCTjY2VW9xcVB0SEJuYzRlTWdCeW1DZmxLMTJlS2ZkMllZeG55ZzljWmF6 CldBNVZzbHZUeHBtNzZoYmc1b2lBRUgvVmcvOE14SHlBblBoZnJnd3lQcm1KRWNWQmFmZHNw Sm5ZUXhCWU5jbzIKTEZQSWhsT3ZXaDhyNGF0K3MrTTNMYjI2b1VUY3psZ2RXMVNmM1NEQTc3 Qk1SbkYwRlF5RSs3QXpWNzlNQk40eQpraXFhZXpReHRhRjFGeS90dmtoZmZTbzh1K2R3RzBF Z0poK3RlMzhnVGNJU1ZyMEdJUHBsTHo2WWhqcmJIclBSCkYxQ041VXVMOURCR2p4dU4zNVJM TlZFZnRhNlJVRmxSNk5jdFRqdnJBQkVCQUFHSkFpVUVHQUVDQUE4RkFreUEKY21RQ0d3d0ZD UkxNQXdBQUNna1E3WmZwRG1LcWZqU3JIQS8rS3pBS3ZUeFJoQTlNV05MeEl5SjdTNXVKMTZn cwpUM29DalpyQktHRWhLTU9HWDRPMEdBNlZPRXJ5TzdRUkNDWWFoM294U0czOElBbk5laXdK WGdVOUJ6a2s4NVVHCmJQRWQ3SEdGL1ZTZUhDUXdXb3U2anFVRFRTRHZuOVloTlRkRzBLWFBN NzRhQyt4cjJab3cxTzJtaFhpaGdXS0QKMER3KzBMWVBuVU9zUTBLT0Z4SFhYWUhtUnJTMU9a UFU1OUJMdmMrVFJoSWhhZlNIS0x3YlhLKzZja2t4Qng2aAo4ejVjY3BHMFFzNGJGaGRGWW5G ckVpZURMb0dtbkUyWUxoZFY2c3dKOVZOQ1M2cExpRW9oVDNmbTdhWG0xNXRaCk9JeXpNWmhI UlNBUGJsWHhRMFpTV2pxOG9ScmNZTkZ4YzRXMVVScEFrQkNPWUpvWHZRZkQ1TDNscUFsOFRD cUQKVXpZeGhIL3RKaGJEZEhycUhINzY3amFEYVRCMStUYWxwLzJBTUt3Y1hOT2Rpa2xHeGJt SFZHNllHbDZnOExyYgpzdTlOWkVJNHlMbEh6dWlrdGhKV2d6KzN2WmhWR3lObHQrSE5Jb0Y2 Q2pETDJvbXU1Y0VxNFJESE00NFFxUGs2Cmw3TzBwVXZOMW1UNEIrUzFiMDhSS3BxbS9mZjAx NUUzN0hOVi9waUl2Smx4R0FZejhQU2Z1R0NCMXRoTVlxbG0KZ2RoZDkvQmFiR0ZiR0dZSEE2 VTQvVDV6cVUrZjZ4SHkxU3NBUVoxTVNLbEx3ZWtCSVQrNC9jTFJHcUNIam5WMApxNUgvVDZh N3Q1bVBrYnpTck9MU280cHVqK0lUb05qWXlZSURCV3pobEExOWF2T2ErcnZVam1IdEQzc0ZO N2NYCld0a0dvaThidU5jYnk0VT0KPUFMNm8KLS0tLS1FTkQgUEdQIFBVQkxJQyBLRVkgQkxP Q0stLS0tLQo= Organization: UCLA Computer Science Department Message-ID: Date: Sun, 10 May 2020 12:07:42 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 41001 Cc: 41001@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 5/7/20 7:06 PM, Eric Blake wrote: > > (My personal wish: I would love a variation of mkdir that returns an open fd on > the just-created directory on success in a single syscall, Yes! That would be a worthy addition. From unknown Fri Jun 20 07:28:15 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Mon, 08 Jun 2020 11:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator