From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 116704 invoked by alias); 28 Aug 2019 13:36:45 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 116696 invoked by uid 89); 28 Aug 2019 13:36:45 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy= X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 28 Aug 2019 13:36:44 +0000 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 03BF23175296 for ; Wed, 28 Aug 2019 13:36:43 +0000 (UTC) Received: from [10.3.116.234] (ovpn-116-234.phx2.redhat.com [10.3.116.234]) by smtp.corp.redhat.com (Postfix) with ESMTPS id BC16F600CD for ; Wed, 28 Aug 2019 13:36:42 +0000 (UTC) Subject: Re: Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ... To: cygwin@cygwin.com References: <20190827152549.GY11632@calimero.vinschen.de> <3E262D05-F393-453A-9E43-B248DDE50812@solidrocksystems.com> <20190828125939.GL11632@calimero.vinschen.de> From: Eric Blake Openpgp: preference=signencrypt Message-ID: <421ac447-b249-da21-1ca5-228041cfc884@redhat.com> Date: Wed, 28 Aug 2019 14:16:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20190828125939.GL11632@calimero.vinschen.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="JNqU72IbvBM8GcnG5C5WFeHsDUswI5mV6" X-IsSubscribed: yes X-SW-Source: 2019-08/txt/msg00368.txt.bz2 --JNqU72IbvBM8GcnG5C5WFeHsDUswI5mV6 Content-Type: multipart/mixed; boundary="V2q6vqQW4tAbrjGUQ6PzPJNT4uMfWkpAX"; protected-headers="v1" From: Eric Blake To: cygwin@cygwin.com Message-ID: <421ac447-b249-da21-1ca5-228041cfc884@redhat.com> Subject: Re: Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ... References: <20190827152549.GY11632@calimero.vinschen.de> <3E262D05-F393-453A-9E43-B248DDE50812@solidrocksystems.com> <20190828125939.GL11632@calimero.vinschen.de> In-Reply-To: <20190828125939.GL11632@calimero.vinschen.de> --V2q6vqQW4tAbrjGUQ6PzPJNT4uMfWkpAX Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Content-length: 1400 On 8/28/19 7:59 AM, Corinna Vinschen wrote: >>>>> mkdir(2) has some special code from 2009 which drops trailing >>>>> {back}slashes to perform a bordercase in mkdir Linux-compatible. >>>>> This code snippet doesn't exist in rmdir(2). Dropping trailing slashes to be Linux-compatible is okay. Dropping trailing backslashes is risky, though, if it makes us forget that the user was asking for a DOS path (even though DOS paths are not always going to work as expected). >=20 > Eric, any insight? As usual our comments from way back when are lacking > in terms of what exact problem this code is trying to fix/workaround. If I recall, we had cases where 'mkdir a/' and 'mkdir a' did not behave identically, even though POSIX says they should; compounded by the fact that Windows treats trailing slash differently when performing native mkdir on a drive than it does on a subdirectory of a drive. It may be as simple as changing the isdirsep() from the identified commit to instead check only for '/' (and ignore '\'). >=20 > Given this case, I wonder if we really need this code or if we can't > just drop it. Of course, it would be great to learn what bordercase > this code was trying to handle and if there isn't another way to do that. >=20 >=20 > Corinna >=20 --=20 Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org --V2q6vqQW4tAbrjGUQ6PzPJNT4uMfWkpAX-- --JNqU72IbvBM8GcnG5C5WFeHsDUswI5mV6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" Content-length: 488 -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEccLMIrHEYCkn0vOqp6FrSiUnQ2oFAl1mg2kACgkQp6FrSiUn Q2relQgAqHIASHcD0vE0YYfQYdfXSmlZVXaLgIVRP/+LnrSG6SRqU0m2qjQRBk74 pYy698zpbcjjATqOq4CdFHitxltGUx3Wi7ZCWTuiSQ9LtQ2ve6BWPJebYK5KHiK/ pHMiTkYvce3qrTF8kpn7+6dgS7wZzD9v1nCWM1vBF9eeB51A9hkPE4yj3c6XnUii /0BVU15hmv2OTKv5+HrnHHFi/2b+7g7bDi5SVgT4b9v4fB8YXEqhz6Ku0UPb6Gp+ cd7fXvWMV/uM+1KNukmQIlh7eGJ/FtaS4ch6QmxMoRYOqnV0bbBAAf4K8lfSGvFS 0stTafC+2Wzj3DWI/tRoJ9MOMjx7eA== =PQfp -----END PGP SIGNATURE----- --JNqU72IbvBM8GcnG5C5WFeHsDUswI5mV6--