From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 18 16:01:26 2016 Received: (at submit) by debbugs.gnu.org; 18 Oct 2016 20:01:26 +0000 Received: from localhost ([127.0.0.1]:38388 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bwaZi-0004ZK-H3 for submit@debbugs.gnu.org; Tue, 18 Oct 2016 16:01:26 -0400 Received: from eggs.gnu.org ([208.118.235.92]:41430) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bwaZh-0004TM-65 for submit@debbugs.gnu.org; Tue, 18 Oct 2016 16:01:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bwaZa-000731-U7 for submit@debbugs.gnu.org; Tue, 18 Oct 2016 16:01:19 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:49544) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1bwaZa-00072x-Qx for submit@debbugs.gnu.org; Tue, 18 Oct 2016 16:01:18 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60614) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bwaZZ-0001Dy-P1 for bug-coreutils@gnu.org; Tue, 18 Oct 2016 16:01:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bwaZW-000710-O8 for bug-coreutils@gnu.org; Tue, 18 Oct 2016 16:01:17 -0400 Received: from ishtar.tlinx.org ([173.164.175.65]:40088 helo=Ishtar.sc.tlinx.org) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1bwaZW-0006wY-F6 for bug-coreutils@gnu.org; Tue, 18 Oct 2016 16:01:14 -0400 Received: from [192.168.3.12] (Athenae [192.168.3.12]) by Ishtar.sc.tlinx.org (8.14.7/8.14.4/SuSE Linux 0.8) with ESMTP id u9IK11s0031697 for ; Tue, 18 Oct 2016 13:01:04 -0700 Message-ID: <58067CD8.2080501@tlinx.org> Date: Tue, 18 Oct 2016 12:49:44 -0700 From: "L. A. Walsh" User-Agent: Thunderbird MIME-Version: 1.0 To: bug-coreutils@gnu.org Subject: rmdir/mkdir error(s) and/or not working "reciprocally" w/each other Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x (no timestamps) [generic] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -5.0 (-----) 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: -5.0 (-----) It doesn't seem rmdir and mkdir are behaving "reciprocally"... If I type mkdir -p ./a/b/c # no error rmdir -p ./a/b/c # get error msg, but a,b,c removed. 1) thinking either rmdir shouldn't generate an error or mkdir should mkdir -p a/../b # no error rmdir -p a/../b # error, but a & b removed 2) similar comment to above -- leading to: for rmdir, if "-p" is used, then as similar to "mkdir -p": (no error if existing, make parent directories as needed) rmdir -p should be "no error if dir not empty, but directories are followed and deleted as possible". ======> seems to be best wording & solution: "mkdir -p", it seems should really be restated to: follow given path and make directories as possible" then "rmdir -p" could be "follow given path and delete directories if empty" Does that look reasonable? linda w. From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 18 16:33:53 2016 Received: (at control) by debbugs.gnu.org; 18 Oct 2016 20:33:53 +0000 Received: from localhost ([127.0.0.1]:38413 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bwb57-0005YQ-Bt for submit@debbugs.gnu.org; Tue, 18 Oct 2016 16:33:53 -0400 Received: from mx1.redhat.com ([209.132.183.28]:32860) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bwb55-0005Y7-5O; Tue, 18 Oct 2016 16:33:51 -0400 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 105C031B318; Tue, 18 Oct 2016 20:33:45 +0000 (UTC) Received: from [10.3.116.151] (ovpn-116-151.phx2.redhat.com [10.3.116.151]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9IKXig3013372; Tue, 18 Oct 2016 16:33:44 -0400 Subject: Re: bug#24730: rmdir/mkdir error(s) and/or not working "reciprocally" w/each other To: "L. A. Walsh" , 24730-done@debbugs.gnu.org References: <58067CD8.2080501@tlinx.org> From: Eric Blake Openpgp: url=http://people.redhat.com/eblake/eblake.gpg Organization: Red Hat, Inc. Message-ID: Date: Tue, 18 Oct 2016 15:33:43 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <58067CD8.2080501@tlinx.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="hex0VFXRbwTO7tIr0XqqvHlQr3HEBlbtf" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Tue, 18 Oct 2016 20:33:45 +0000 (UTC) X-Spam-Score: -5.3 (-----) 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: -5.3 (-----) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hex0VFXRbwTO7tIr0XqqvHlQr3HEBlbtf Content-Type: multipart/mixed; boundary="HdqBE4sdMTo2SVjHxWrWdV24sBJ3UrgFt"; protected-headers="v1" From: Eric Blake To: "L. A. Walsh" , 24730-done@debbugs.gnu.org Message-ID: Subject: Re: bug#24730: rmdir/mkdir error(s) and/or not working "reciprocally" w/each other References: <58067CD8.2080501@tlinx.org> In-Reply-To: <58067CD8.2080501@tlinx.org> --HdqBE4sdMTo2SVjHxWrWdV24sBJ3UrgFt Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable tag 24730 notabug thanks On 10/18/2016 02:49 PM, L. A. Walsh wrote: >=20 > It doesn't seem rmdir and mkdir are behaving "reciprocally"... >=20 > If I type >=20 > mkdir -p ./a/b/c # no error =2E already exists, so mkdir silently does nothing, =2E/a needs to be created, =2E/a/b needs to be created, =2E/a/b/c needs to be created > rmdir -p ./a/b/c # get error msg, but a,b,c removed. =2E/a/b/c needs to be removed, =2E/a/b needs to be removed, =2E/a needs to be removed, =2E needs to be removed, but you can't do that, hence the error The apparent asymmetry is due to the POSIX rules on how '.' is treated; but we can't change the behavior of either of these commands, because they are both following the POSIX rules. If you want symmetry, omit the leading './', as in: $ mkdir -p a/b/c $ rmdir -p a/b/c >=20 > 1) thinking either rmdir shouldn't generate an error or mkdir should >=20 > mkdir -p a/../b # no error a needs to be created, a/.. already exists, so it silently does nothing, a/../b needs to be created > rmdir -p a/../b # error, but a & b removed a/../b needs to be removed, a/.. needs to be removed, but you can't do that, at this point, POSIX is fuzzy whether to attempt to remove 'a', or to give up since 'a/..' was already an error; but obviously coreutils removes 'a' >=20 > 2) similar comment to above -- leading to: >=20 > for rmdir, if "-p" is used, then as similar to "mkdir -p": > (no error if existing, make parent directories as needed) >=20 > rmdir -p should be > "no error if dir not empty, but directories are followed > and deleted as possible". Sadly, while that might be a nicer definition for 'rmdir -p', it doesn't match the POSIX requirements nor the historical behavior, so we can't really change it now. So I'm marking this as not a bug, as there is nothing to change. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --HdqBE4sdMTo2SVjHxWrWdV24sBJ3UrgFt-- --hex0VFXRbwTO7tIr0XqqvHlQr3HEBlbtf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJYBocnAAoJEKeha0olJ0NqXmUH+wUyvTV8FwXh6ZmvVivwIt4m m0bb2CFs/EYpQDrz3G+onto1r8VWyc6FHR0NW+KUrwEuSKjtd/a+GMv7iOkq52gl 2rnzOnQXY0J1U8IgUxSGrZPsnbBox0wtHWh2AQb4UF9CvL1iVwjMkufk8n9P2eaV P8X4IVhFzShBDpeg1a6QoQSgLgEKrO4CPl7b8SayzBrJvWi0X9rye5Pc8Xebx/Xl JscEfCKuLtBIyU0Hgvfid6hNRApm9RobvqV/wa3tDMVPM2pPr/EmnCSB29dQ92vc NyTd3sUD3jnt174WuO3VHmssyjcv0x+W04UGzCOAP9ieAt1/X1aIWECHyGCMv34= =Lq1t -----END PGP SIGNATURE----- --hex0VFXRbwTO7tIr0XqqvHlQr3HEBlbtf-- From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 18 16:51:12 2016 Received: (at 24730-done) by debbugs.gnu.org; 18 Oct 2016 20:51:12 +0000 Received: from localhost ([127.0.0.1]:38442 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bwbLs-0007bY-3s for submit@debbugs.gnu.org; Tue, 18 Oct 2016 16:51:12 -0400 Received: from vhrz24.hrz.uni-marburg.de ([137.248.1.34]:57224) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bwbLq-0007bL-BG for 24730-done@debbugs.gnu.org; Tue, 18 Oct 2016 16:51:10 -0400 Received: from [10.0.1.5] (pD9E3C0F0.dip0.t-ipconnect.de [217.227.192.240]) (authenticated bits=0) by vhrz24.HRZ.Uni-Marburg.DE (8.14.4/8.14.4/Debian-8+deb8u1) with ESMTP id u9IKoweI021321 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 18 Oct 2016 22:51:00 +0200 Subject: Re: bug#24730: rmdir/mkdir error(s) and/or not working "reciprocally" w/each other Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Reuti In-Reply-To: Date: Tue, 18 Oct 2016 22:50:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <92525368-A926-4B03-80A1-1959B9C48CBB@staff.uni-marburg.de> References: <58067CD8.2080501@tlinx.org> To: Eric Blake X-Pgp-Agent: GPGMail 1.4.1 X-Mailer: Apple Mail (2.1085) X-Null-Tag: cac75c011c6e44c66f71bef66b3b8916 X-UniMR-MailScanner-Information: see http://www.uni-marburg.de/hrz/internet/mail/spam/ X-UniMR-MailScanner-ID: u9IKoweI021321 X-UniMR-MailScanner: Found to be clean X-UniMR-MailScanner-From: reuti@staff.uni-marburg.de X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 24730-done Cc: 24730-done@debbugs.gnu.org, "L. A. Walsh" 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: -2.6 (--) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 18.10.2016 um 22:33 schrieb Eric Blake: > tag 24730 notabug > thanks >=20 > On 10/18/2016 02:49 PM, L. A. Walsh wrote: >>=20 >> It doesn't seem rmdir and mkdir are behaving "reciprocally"... >>=20 >> If I type >>=20 >> mkdir -p ./a/b/c # no error >=20 > . already exists, so mkdir silently does nothing, > ./a needs to be created, > ./a/b needs to be created, > ./a/b/c needs to be created >=20 >> rmdir -p ./a/b/c # get error msg, but a,b,c removed. >=20 > ./a/b/c needs to be removed, > ./a/b needs to be removed, > ./a needs to be removed, > . needs to be removed, but you can't do that, hence the error >=20 > The apparent asymmetry is due to the POSIX rules on how '.' is = treated; > but we can't change the behavior of either of these commands, because > they are both following the POSIX rules. >=20 > If you want symmetry, omit the leading './', as in: >=20 > $ mkdir -p a/b/c > $ rmdir -p a/b/c >=20 >>=20 >> 1) thinking either rmdir shouldn't generate an error or mkdir should >>=20 >> mkdir -p a/../b # no error >=20 > a needs to be created, > a/.. already exists, so it silently does nothing, > a/../b needs to be created >=20 >> rmdir -p a/../b # error, but a & b removed >=20 > a/../b needs to be removed, > a/.. needs to be removed, but you can't do that, > at this point, POSIX is fuzzy whether to attempt to remove 'a', or to > give up since 'a/..' was already an error; but obviously coreutils > removes 'a' What version of core-utils shows this behavior. In the latest one it's = not removed AFAICS. - -- Reuti >=20 >>=20 >> 2) similar comment to above -- leading to: >>=20 >> for rmdir, if "-p" is used, then as similar to "mkdir -p": >> (no error if existing, make parent directories as needed) >>=20 >> rmdir -p should be >> "no error if dir not empty, but directories are followed >> and deleted as possible". >=20 > Sadly, while that might be a nicer definition for 'rmdir -p', it = doesn't > match the POSIX requirements nor the historical behavior, so we can't > really change it now. >=20 > So I'm marking this as not a bug, as there is nothing to change. >=20 > --=20 > Eric Blake eblake redhat com +1-919-301-3266 > Libvirt virtualization library http://libvirt.org >=20 -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iEYEARECAAYFAlgGizIACgkQo/GbGkBRnRrB9ACgpbqqSW0ZF27H5nSKF97zrDth kLMAnRDKMmGxZ9p2SAqp/g+8AIkinqtU =3DykPn -----END PGP SIGNATURE----- From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 18 16:54:38 2016 Received: (at 24730-done) by debbugs.gnu.org; 18 Oct 2016 20:54:38 +0000 Received: from localhost ([127.0.0.1]:38446 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bwbPC-0007gK-KM for submit@debbugs.gnu.org; Tue, 18 Oct 2016 16:54:38 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33360) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bwbPB-0007g8-10 for 24730-done@debbugs.gnu.org; Tue, 18 Oct 2016 16:54:37 -0400 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 64A16C056791; Tue, 18 Oct 2016 20:54:31 +0000 (UTC) Received: from [10.3.116.151] (ovpn-116-151.phx2.redhat.com [10.3.116.151]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9IKsUUY002417; Tue, 18 Oct 2016 16:54:30 -0400 Subject: Re: bug#24730: rmdir/mkdir error(s) and/or not working "reciprocally" w/each other To: Reuti References: <58067CD8.2080501@tlinx.org> <92525368-A926-4B03-80A1-1959B9C48CBB@staff.uni-marburg.de> From: Eric Blake Openpgp: url=http://people.redhat.com/eblake/eblake.gpg Organization: Red Hat, Inc. Message-ID: <4a4faa1c-086c-af4e-4ca8-fd597cb1b278@redhat.com> Date: Tue, 18 Oct 2016 15:54:30 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <92525368-A926-4B03-80A1-1959B9C48CBB@staff.uni-marburg.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="a0rmMviBTVuE9IuW6hSJwO3f32JwDvdnI" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Tue, 18 Oct 2016 20:54:31 +0000 (UTC) X-Spam-Score: -5.3 (-----) X-Debbugs-Envelope-To: 24730-done Cc: 24730-done@debbugs.gnu.org, "L. A. Walsh" 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: -5.3 (-----) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --a0rmMviBTVuE9IuW6hSJwO3f32JwDvdnI Content-Type: multipart/mixed; boundary="DXaig01m2iu5jSG43g8BIptjFIxcISRCr"; protected-headers="v1" From: Eric Blake To: Reuti Cc: "L. A. Walsh" , 24730-done@debbugs.gnu.org Message-ID: <4a4faa1c-086c-af4e-4ca8-fd597cb1b278@redhat.com> Subject: Re: bug#24730: rmdir/mkdir error(s) and/or not working "reciprocally" w/each other References: <58067CD8.2080501@tlinx.org> <92525368-A926-4B03-80A1-1959B9C48CBB@staff.uni-marburg.de> In-Reply-To: <92525368-A926-4B03-80A1-1959B9C48CBB@staff.uni-marburg.de> --DXaig01m2iu5jSG43g8BIptjFIxcISRCr Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10/18/2016 03:50 PM, Reuti wrote: >>> >>> 1) thinking either rmdir shouldn't generate an error or mkdir should >>> >>> mkdir -p a/../b # no error >=20 >> a needs to be created, >> a/.. already exists, so it silently does nothing, >> a/../b needs to be created >=20 >>> rmdir -p a/../b # error, but a & b removed >=20 >> a/../b needs to be removed, >> a/.. needs to be removed, but you can't do that, >> at this point, POSIX is fuzzy whether to attempt to remove 'a', or to >> give up since 'a/..' was already an error; but obviously coreutils >> removes 'a' >=20 > What version of core-utils shows this behavior. In the latest one it's = not removed AFAICS. Hmm, you're right. I was going off the (incorrect) comment in the text above, rather than actually testing it; so it looks like coreutils gives up on the first error, rather than trying to remove a. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --DXaig01m2iu5jSG43g8BIptjFIxcISRCr-- --a0rmMviBTVuE9IuW6hSJwO3f32JwDvdnI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJYBowGAAoJEKeha0olJ0NqS20H/2fvb+6rfddqvGMAiXf3H3PZ Hia6HGid3RWPphngHteoyNsKsOfOqVMWCDFC6uY+9G/qoZnGReVzyCf/4dnAWRRi fsOoHhl8XvAj+1E7ZrdeP668Bvw/5LHrT9ZQHR38dWKHlqDRBeQ58jiH2JhkxtkZ doSOdIEHEieCk8vCNS7q7FDIgwurHnI9ez9X69UtR3A2k/nvNeOtCnmodBahn+iY OdQwwkjTza3DJUggEGAVzQtC01pYyf1iVdN1/Qe5IW7jk+LlFzbfpT+u4KRTx+xh Qs3rbqocTfzzEIgHMrhuOkIWuCFwVQpkxMjY8Y2Wx2mhhZb8mJQr5fZnHfauYVU= =lCAn -----END PGP SIGNATURE----- --a0rmMviBTVuE9IuW6hSJwO3f32JwDvdnI-- From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 18 16:57:53 2016 Received: (at 24730) by debbugs.gnu.org; 18 Oct 2016 20:57:53 +0000 Received: from localhost ([127.0.0.1]:38452 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bwbSL-0007l4-40 for submit@debbugs.gnu.org; Tue, 18 Oct 2016 16:57:53 -0400 Received: from mail-qk0-f169.google.com ([209.85.220.169]:36793) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bwbSJ-0007kp-KH for 24730@debbugs.gnu.org; Tue, 18 Oct 2016 16:57:52 -0400 Received: by mail-qk0-f169.google.com with SMTP id o68so7992833qkf.3 for <24730@debbugs.gnu.org>; Tue, 18 Oct 2016 13:57:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=E16gI28zd++pgsicWNLzuFIGns7OJdMthUDjvQdXmps=; b=cuqfwwJNME2Vz/OyghicXQv+fSWrzA0O5MY3gg6DavLSriGQsR1tsawK3xxRTSu+dG t8yH5M3nxVgdKTHg+BNT3e2uIyveAu0TSFqcXM4/YI2Ur28XBDeCMJ2K0TmGlsH3KVeg FNvW1sVWOX4b97NtVd4C4PEL1PQ1oQA64UeE7OYc29BxfigWMV8dxKpG6UMC+Wx8yY8d CMRzSBK6TKCxCEXnEwUMpA1Ci2ku1aKHAh5JjMoM2PJMkSLRU+j1apvN6EZzyDTktDA9 bp09nM0op/a12PfIIWtlNvdj3xnoCRug16kq4oEm4xn6lYz6djqf8K3oRRRUs8YJRAPz WCmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=E16gI28zd++pgsicWNLzuFIGns7OJdMthUDjvQdXmps=; b=TpswkS/0bmVjiu5u4pQFkHEjk+W3B/ngCIM2bbGC2hyXksYJjfnV/4RyxtNJI3jTV1 4HxoShvKOTT6AbPEwDe8mgpFD7jK44QYocmlwiSdjF6Zk4Y6GXI9a/yJErQ3JkOIEq6t y6VJ9Mwy8M/ziPFD/Gm89HYkQM1ArZ9o6LwjXjVQW5UEWckQn8efjwibfdEEBVJt1oai qcfGBVLorWqj7xrZhsWLT6XbNjwNVFjYaQXsYMyH4P0gsWcsDqVG9fIIIDnkv67kHqx/ 5ir+bMBMRrGUeCpot86f6iODiRCFXdiAcjgKvvWdXQhUb4lQktUw0G94bzhQf0IspLCS mjeg== X-Gm-Message-State: AA6/9RmzFnGJ9ngjJ7/ycuGoNRoHtzRENrse1uTnvIWWOcAdR31xpgpvLhFCbmGJOnDLUQ== X-Received: by 10.55.45.193 with SMTP id t184mr2491196qkh.58.1476824265997; Tue, 18 Oct 2016 13:57:45 -0700 (PDT) Received: from disco.erlich.nygenome.org ([69.74.14.178]) by smtp.gmail.com with ESMTPSA id g63sm19000895qkf.47.2016.10.18.13.57.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Oct 2016 13:57:45 -0700 (PDT) Subject: Re: bug#24730: rmdir/mkdir error(s) and/or not working "reciprocally" w/each other To: "L. A. Walsh" , 24730@debbugs.gnu.org References: <58067CD8.2080501@tlinx.org> From: Assaf Gordon Message-ID: <62762ce8-36ca-b1b0-f6fc-37e0fb35ef88@gmail.com> Date: Tue, 18 Oct 2016 16:57:45 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <58067CD8.2080501@tlinx.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 24730 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: 0.5 (/) Hello, Before deciding on the wording, it's worth nothing that the errors and reasons for the errors are different between mkdir and rmdir, and between the two cases. On 10/18/2016 03:49 PM, L. A. Walsh wrote: > mkdir -p ./a/b/c # no error > rmdir -p ./a/b/c # get error msg, but a,b,c removed. The error in this case (at least on Linux) is "Invalid Argument", because 'rmdir .' is invalid and rejected by the kernel (EINVAL) while 'mkdir .' returns EEXISTS - and '-p' specifically instruct it to silently ignore EEXIST. Demonstrated another way: 'mkdir' without -p: $ strace -e mkdir mkdir . mkdir(".", 0777) = -1 EEXIST (File exists) mkdir: cannot create directory ‘.’: File exists +++ exited with 1 +++ 'mkdir' with -p: $ strace -e mkdir mkdir -p . mkdir(".", 0777) = -1 EEXIST (File exists) +++ exited with 0 +++ but 'rmdir' gives an unrecoverable error because of the kernel, not because of coreutils' code: $ strace -e rmdir rmdir . rmdir(".") = -1 EINVAL (Invalid argument) rmdir: failed to remove '.': Invalid argument This is also mandated by posix: http://pubs.opengroup.org/onlinepubs/9699919799/functions/rmdir.html "If the path argument refers to a path whose final component is either dot or dot-dot, rmdir() shall fail." However, if there is no dot component in the path, they do behave similarly (or reciprocally, as you've said). > mkdir -p a/../b # no error > rmdir -p a/../b # error, but a & b removed At least on my system (Linux kernel 3.13), 'a' is not removed in the above example, and the error is due to non-empty directory: $ strace -e mkdir mkdir -p a/../b mkdir("a", 0777) = 0 mkdir("b", 0777) = 0 +++ exited with 0 +++ $ strace -e rmdir rmdir -p a/../b rmdir("a/../b") = 0 rmdir("a/..") = -1 ENOTEMPTY (Directory not empty) rmdir: failed to remove directory 'a/..': Directory not empty +++ exited with 1 +++ So two cases these are slightly different (EINVAL vs ENOTEMPTY). Note that coreutils' mkdir contains an optimization not to try and make '..' as it is guaranteed to exist (implemented in gnulib's mkancesdirs.c). However, by definition, when 'rmdir' traverses the directories on the given path, the directory 'a/..' is not empty (it contains 'a') - so this must fail. If you want to 'rmdir' to silently ignore non-empty directories, there's a gnu extension option of 'rmdir --ignore-fail-on-non-empty': $ strace -e rmdir rmdir --ignore-fail-on-non-empty -p a/../b rmdir("a/../b") = 0 rmdir("a/..") = -1 ENOTEMPTY (Directory not empty) +++ exited with 0 +++ But note that this causes 'rmdir' to stop upon first failure, and 'a' is still not removed. > ======> seems to be best wording & solution: > > "mkdir -p", it seems should really be restated to: > > follow given path and make directories as possible" > > then "rmdir -p" could be > > "follow given path and delete directories if empty" This does not accurately reflect how 'rmdir' is currently implemented. A more accurate description is "follow given path and delete directories, until the first encountered failure". $ mkdir -p a/../b/../c/../d $ strace -e rmdir rmdir -p a/../b/../c/../d rmdir("a/../b/../c/../d") = 0 rmdir("a/../b/../c/..") = -1 ENOTEMPTY (Directory not empty) rmdir: failed to remove directory 'a/../b/../c/..': Directory not empty +++ exited with 1 +++ $ ls a b c If you want a behavior where 'rmdir' will continue beyond the first failure and try to delete all directories in the given path (e.g. a/b/c in the example above), then it sounds like a new feature request, and a non-standard behavior which will be a gnu extension (and also quite confusing behavior, IMHO). regards, - assaf From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 18 17:47:19 2016 Received: (at 24730) by debbugs.gnu.org; 18 Oct 2016 21:47:19 +0000 Received: from localhost ([127.0.0.1]:38475 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bwcEA-0000VS-Q3 for submit@debbugs.gnu.org; Tue, 18 Oct 2016 17:47:19 -0400 Received: from ishtar.tlinx.org ([173.164.175.65]:42696 helo=Ishtar.sc.tlinx.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bwcE8-0000VJ-U6 for 24730@debbugs.gnu.org; Tue, 18 Oct 2016 17:47:17 -0400 Received: from [192.168.3.12] (Athenae [192.168.3.12]) by Ishtar.sc.tlinx.org (8.14.7/8.14.4/SuSE Linux 0.8) with ESMTP id u9ILlCbr040358; Tue, 18 Oct 2016 14:47:14 -0700 Message-ID: <580695BB.2030503@tlinx.org> Date: Tue, 18 Oct 2016 14:35:55 -0700 From: Linda Walsh User-Agent: Thunderbird MIME-Version: 1.0 To: Assaf Gordon Subject: Re: bug#24730: rmdir/mkdir error(s) and/or not working "reciprocally" w/each other References: <58067CD8.2080501@tlinx.org> <62762ce8-36ca-b1b0-f6fc-37e0fb35ef88@gmail.com> In-Reply-To: <62762ce8-36ca-b1b0-f6fc-37e0fb35ef88@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.3 (/) X-Debbugs-Envelope-To: 24730 Cc: 24730@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: -0.3 (/) Assaf Gordon wrote: > Hello, > > Before deciding on the wording, it's worth nothing that the errors and > reasons for the errors are different between mkdir and rmdir, and > between the two cases. > > On 10/18/2016 03:49 PM, L. A. Walsh wrote: > >> mkdir -p ./a/b/c # no error >> rmdir -p ./a/b/c # get error msg, but a,b,c removed. > > The error in this case (at least on Linux) is "Invalid Argument", > because 'rmdir .' is invalid and rejected by the kernel (EINVAL) > while 'mkdir .' returns EEXISTS - and '-p' specifically instruct it to > silently ignore EEXIST. ---- I see... so in ".a/b/c", a,b,c are removed, but the error comes in "."? > $ strace -e rmdir rmdir . > rmdir(".") = -1 EINVAL (Invalid argument) > rmdir: failed to remove '.': Invalid argument > > This is also mandated by posix: > http://pubs.opengroup.org/onlinepubs/9699919799/functions/rmdir.html > "If the path argument refers to a path whose final component is > either dot or dot-dot, rmdir() shall fail." --- Ok, but is "-p" a posix switch in mkdir or rmdir? If not, wouldn't the behavior be undefined? >> mkdir -p a/../b # no error >> rmdir -p a/../b # error, but a & b removed > > At least on my system (Linux kernel 3.13), 'a' is not removed in the > above example, > and the error is due to non-empty directory: --- Right..., my bad, only checked 'b'. (*duh*) > Note that coreutils' mkdir contains an optimization not to try and make > '..' as it is > guaranteed to exist (implemented in gnulib's mkancesdirs.c). --- Right, same when rmdir traverses, when it hits "..", that must exist (even in '/'). > However, by definition, when 'rmdir' traverses the directories on the > given path, > the directory 'a/..' is not empty (it contains 'a') - so this must fail. ---- with "-p"? Am talking about the case where you create a dir with "mkdir -p "$dirname" and later, rmdir -p "$dirname" (where dirname is passed as a parameter, but is not user-input). > > > If you want to 'rmdir' to silently ignore non-empty directories, > there's a gnu extension option of 'rmdir --ignore-fail-on-non-empty': > > $ strace -e rmdir rmdir --ignore-fail-on-non-empty -p a/../b > rmdir("a/../b") = 0 > rmdir("a/..") = -1 ENOTEMPTY (Directory > not empty) > +++ exited with 0 +++ > > But note that this causes 'rmdir' to stop upon first failure, and 'a' is > still not removed. > >> ======> seems to be best wording & solution: >> >> "mkdir -p", it seems should really be restated to: >> >> follow given path and make directories as possible" >> >> then "rmdir -p" could be >> >> "follow given path and delete directories if empty" > > This does not accurately reflect how 'rmdir' is currently implemented. > A more accurate description is "follow given path and delete > directories, until the first encountered failure". ---- Right, but am trying to get rmdir to be a useful "opposite" to a "mkdir" -- at least w/r/t "-p"... > If you want a behavior where 'rmdir' will continue beyond the first failure > and try to delete all directories in the given path (e.g. a/b/c in the > example above), > then it sounds like a new feature request, and a non-standard behavior > which will be a gnu extension (and also quite confusing behavior, IMHO). --- Yeah -- new feature, but confusing? I think the fact that you can mkdir -p XXX and later canNOT rmdir -p XXX, is quite confusing behavior... But is -p's behavior in mkdir and rmdir mandated by POSIX? From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 18 20:14:39 2016 Received: (at 24730) by debbugs.gnu.org; 19 Oct 2016 00:14:39 +0000 Received: from localhost ([127.0.0.1]:38530 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bweWl-0005ee-2a for submit@debbugs.gnu.org; Tue, 18 Oct 2016 20:14:39 -0400 Received: from mail-qk0-f178.google.com ([209.85.220.178]:35031) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bweWj-0005eR-KF for 24730@debbugs.gnu.org; Tue, 18 Oct 2016 20:14:38 -0400 Received: by mail-qk0-f178.google.com with SMTP id z190so12844886qkc.2 for <24730@debbugs.gnu.org>; Tue, 18 Oct 2016 17:14:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/KK9Shr1aJbOq7+19o1OawxzZrWWIx2d8uYO/iNqf2E=; b=NyzDvOYzwmuzH57J7QIrENhv8kNJXjbq393vRIJl2ZskjngjApe6fVU+SLVXULq/jA wvMjcSYnYnnTier5yYwZXViKmXW5fIHwa8bW4rnfK1qHUptp23CEp7BrDYTcOLTcr+NA alfUfiIs6cUzKwVU1IfPV/B9/6bp9eUD8JtTuU+4/DGMIdsXTWPzgWHrJGggMZC0/9vx yvnbFP92cOb//ozZnvE04C0S4U8+6Eeh2Npbi2CaMstnqNbHAC4bHFjpyUZxNgl/1CNj 3uxhuWOv9vl4mFwlJepc+35RnhAAoArrrvMeuxpfxkegPFIwZEOtyuqJoYOdtIdRYzds wr+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/KK9Shr1aJbOq7+19o1OawxzZrWWIx2d8uYO/iNqf2E=; b=bChDmDtUDQTfb1QWWgSbSnoLyTC+UwWSkCD7zGzrszROdgfwjbFnfrvlvaGq22B5st yfXRBJV+Rpo6jbs5G0/K20yP0LjLWbzHPUp6k1lgmsTrnhNQSBFlVbrJ+Q/aAu5EF3Oi 6ZnS9bT+C7K5aawZ0fIUgESpPveELqhlmn6A6iS+3mVrA5OBKhZ72H4weSAlx+Vvtftf X9mVC0AITy0Lbrq/q2XDDDfbI3AVWdaQkJg4lNh7GOvgHM+gSlC2VPwVH+iCcvsJ6Ycb UxQJkwuzaYxt6rUwXk5tEMDDHU8LsU4/LSSzVkH20oiWkVi0odAf/gph+p4C4emsoV7c Btig== X-Gm-Message-State: ABUngvcj+YSCjp6nNXbvcb631saVMoGgNwuXWk+jw6L6fLJ0kUkm+sSndFQ2Ny0DUBMBTA== X-Received: by 10.55.203.23 with SMTP id d23mr3602303qkj.143.1476836072121; Tue, 18 Oct 2016 17:14:32 -0700 (PDT) Received: from [172.31.99.244] (rrcs-50-74-108-28.nyc.biz.rr.com. [50.74.108.28]) by smtp.gmail.com with ESMTPSA id p28sm19372036qtb.2.2016.10.18.17.14.30 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 18 Oct 2016 17:14:31 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) Subject: Re: bug#24730: rmdir/mkdir error(s) and/or not working "reciprocally" w/each other From: Assaf Gordon In-Reply-To: <580695BB.2030503@tlinx.org> Date: Tue, 18 Oct 2016 20:14:27 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <33597C39-FA84-44B2-BE06-BE303B9C4FF2@gmail.com> References: <58067CD8.2080501@tlinx.org> <62762ce8-36ca-b1b0-f6fc-37e0fb35ef88@gmail.com> <580695BB.2030503@tlinx.org> To: Linda Walsh X-Mailer: Apple Mail (2.2102) X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 24730 Cc: 24730@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: 0.5 (/) Hello, > On Oct 18, 2016, at 17:35, Linda Walsh wrote: >=20 > Assaf Gordon wrote: >>> rmdir -p ./a/b/c # get error msg, but a,b,c removed. > I see... so in ".a/b/c", a,b,c are removed, but the error > comes in "."? Yes. > Ok, but is "-p" a posix switch in mkdir or rmdir? Yes, it is defined in posix for both mkdir(1) and rmdir(1): http://pubs.opengroup.org/onlinepubs/9699919799/utilities/rmdir.html http://pubs.opengroup.org/onlinepubs/9699919799/utilities/mkdir.html >> However, by definition, when 'rmdir' traverses the directories on the = given path, >> the directory 'a/..' is not empty (it contains 'a') - so this must = fail. > ---- > with "-p"? Am talking about the case where you create a dir = with "mkdir -p "$dirname" > and later, rmdir -p "$dirname" (where dirname is passed as a = parameter, but > is not user-input). Yes. By posix definition, For "rmdir -p DIR" where DIR contains multiple = path components, rmdir should behave as if run with "rmdir -p $(dirname DIR)". And for example: $ dirname "a/../b" a/.. And trying to call rmdir(2) on "a/.." will fail (definitely fails on = Linux kernel, though I suspect on other systems as well). > Right, but am trying to get rmdir to be a useful > "opposite" to a "mkdir" -- at least w/r/t "-p"... "useful" is somewhat subjective. For the more common case of directories without ".." or "." - this works = quite well, and that is very likely the intended goal: mkdir -p a/b/c rmdir -p a/b/c As the current behavior is mandated by POSIX, If you want to suggest a = different behavior, the best place to suggest this is to the posix group ( = https://www.opengroup.org/austin/ ). If the standard for 'rmdir(1)' is modified or adjusted, GNU coreutils = will surely follow suit. > But is -p's behavior in mkdir and rmdir mandated by POSIX? Yes, see above links. regards, - assaf From unknown Sat Jun 14 18:41:42 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Wed, 16 Nov 2016 12:24:03 +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