From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 124093 invoked by alias); 28 Aug 2019 22:43:54 -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 124082 invoked by uid 89); 28 Aug 2019 22:43:54 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,NORMAL_HTTP_TO_IP,NUMERIC_HTTP_ADDR,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.1 spammy=Had, letter, act X-HELO: lb3-smtp-cloud7.xs4all.net Received: from lb3-smtp-cloud7.xs4all.net (HELO lb3-smtp-cloud7.xs4all.net) (194.109.24.31) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 28 Aug 2019 22:43:52 +0000 Received: from tmp.ItH84P6CKz ([83.162.234.136]) by smtp-cloud7.xs4all.net with ESMTPSA id 36fJiYgdFThuu36fKiMBNm; Thu, 29 Aug 2019 00:43:47 +0200 Date: Wed, 28 Aug 2019 22:57:00 -0000 Message-ID: <79c3029bece494538245687c26fccf29@smtp-cloud7.xs4all.net> From: Houder Reply-To: cygwin@cygwin.com To: cygwin@cygwin.com Cc: eblake@redhat.com Subject: Re: Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ... References: <27047198-dba4-091b-8235-fc9150b68fbe@redhat.com> In-Reply-to: <27047198-dba4-091b-8235-fc9150b68fbe@redhat.com> Content-Type: text/plain; charset=UTF-8; format=fixed User-Agent: mua.awk 0.99 X-SW-Source: 2019-08/txt/msg00378.txt.bz2 On Wed, 28 Aug 2019 08:33:05, Eric Blake wrote: > On 8/27/19 7:51 AM, Houder wrote: > > > > 64-@@ mkdir 'e:\' # creates subdirectory e: !!!!! > > Had you typed: > > mkdir 'e:/' > > I would expect subdirectory ./e: to be created. But with 'e:\', that > is a DOS style path, so I would lean towards requiring './e:\' if you > want to create a literal directory named 'e:\', but without the leading > ./ to merely treat 'e:\' as the drive letter and failing with EEXIST > because /cygdrive/e already exists. > > So it sounds like mkdir() could be further improved when something ends > in \ rather than in /. (The behavior when ending in / should not be > changed, though). > > > 64-@@ rmdir 'e:\' # fails, because it refers to /drv/e > > rmdir: failed to remove 'e:\': Directory not empty > > That matches what I would expect - because you did not pass a leading > './', but used a backslash, you used a DOS style path and should be > attempting to act on /cygdrive/e. > > > > 64-@@ rmdir 'e:' > > This, however, is not a DOS path, so it should prefer to act on './e:' > if that exists (and only if it does not exist, then we might consider > ALSO seeing if /cygdrive/e exists before giving up completely). > > > > Yes, I should NOT use "DOS paths" ... > > > https://cygwin.com/cygwin-ug-net/using.html#pathnames-win32 > > > However, I wonder why e:\ is interpreted by mkdir as e:, and as > > /drv/e (that is as e:\) by rmdir. > > mkdir 'e:/' is supposed to be identical to mkdir 'e:'. The problem is > that because we interchange \ with / in a number of places, we have > accidentally ended up with mkdir 'e:\' behaving like mkdir 'e:/' instead > of acting on the DOS path. # note: cygdrive has been remapped to /drv at my place Good gracious! (btw, thank you for the explanation) - 'e:\' is a DOS path - e:/ is not a DOS path (removing the trailing /, yields e:) However, ls -ld e:/ refers to /drv/e (e:/ is interpreted as 'e:\' by ls!) So do rmdir, stat, touch ... (and many other commands) They are all wrong ... Correct? How about e:/foo ????? A DOS path? Does it refer to /drv/e/foo? According to https://cygwin.com/cygwin-ug-net/using.html#pathnames-win32 it is a DOS path (and NOT foo in subdirectory e:) Said differently, e: is a subdirectory, and e:/ is the same thing, because a trailing forward slash is ignored (like Linux does). Correct? Henri -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple