* Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ... @ 2019-08-27 15:25 Houder 2019-08-27 16:28 ` Corinna Vinschen 2019-08-28 13:36 ` Eric Blake 0 siblings, 2 replies; 32+ messages in thread From: Houder @ 2019-08-27 15:25 UTC (permalink / raw) To: cygwin L.S., # note: cygdrive has been remapped to /drv at my place 64-%% uname -a CYGWIN_NT-6.1 Seven 3.0.7(0.338/5/3) 2019-04-30 18:08 x86_64 Cygwin 64-%% mkdir /drv/e mkdir: cannot create directory â/drv/eâ: Permission denied 64-@@ uname -a CYGWIN_NT-6.1 Seven 3.1.0(0.340/5/3) 2019-08-19 10:13 x86_64 Cygwin 64-@@ mkdir /drv/e mkdir: cannot create directory â/drv/eâ: File exists Different error report (which was the objective of Ben Wijen): https://cygwin.com/ml/cygwin-patches/2019-q2/msg00136.html Now, let's play: 64-@@ cygpath -w /drv/e E:\ 64-@@ mkdir 'e:\' # creates subdirectory e: !!!!! 64-@@ rmdir 'e:\' # fails, because it refers to /drv/e rmdir: failed to remove 'e:\': Directory not empty 64-@@ rmdir 'e:' 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. Any reason for this remarkable difference? Regards, 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ... 2019-08-27 15:25 Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' Houder @ 2019-08-27 16:28 ` Corinna Vinschen 2019-08-27 17:01 ` Houder 2019-08-27 19:48 ` Achim Gratz 2019-08-28 13:36 ` Eric Blake 1 sibling, 2 replies; 32+ messages in thread From: Corinna Vinschen @ 2019-08-27 16:28 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1362 bytes --] On Aug 27 14:51, Houder wrote: > L.S., > > # note: cygdrive has been remapped to /drv at my place > > 64-%% uname -a > CYGWIN_NT-6.1 Seven 3.0.7(0.338/5/3) 2019-04-30 18:08 x86_64 Cygwin > 64-%% mkdir /drv/e > mkdir: cannot create directory ‘/drv/e’: Permission denied > > 64-@@ uname -a > CYGWIN_NT-6.1 Seven 3.1.0(0.340/5/3) 2019-08-19 10:13 x86_64 Cygwin > 64-@@ mkdir /drv/e > mkdir: cannot create directory ‘/drv/e’: File exists > > Different error report (which was the objective of Ben Wijen): > > https://cygwin.com/ml/cygwin-patches/2019-q2/msg00136.html > > Now, let's play: > > 64-@@ cygpath -w /drv/e > E:\ > > 64-@@ mkdir 'e:\' # creates subdirectory e: !!!!! > 64-@@ rmdir 'e:\' # fails, because it refers to /drv/e > rmdir: failed to remove 'e:\': Directory not empty > > 64-@@ rmdir 'e:' > > 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. > > Any reason for this remarkable difference? 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). Corinna -- Corinna Vinschen Cygwin Maintainer [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ... 2019-08-27 16:28 ` Corinna Vinschen @ 2019-08-27 17:01 ` Houder 2019-08-27 17:32 ` Vince Rice 2019-08-27 19:48 ` Achim Gratz 1 sibling, 1 reply; 32+ messages in thread From: Houder @ 2019-08-27 17:01 UTC (permalink / raw) To: cygwin On Tue, 27 Aug 2019 17:25:49, Corinna Vinschen wrote: > > On Aug 27 14:51, Houder wrote: [snip] > > Now, let's play: > > > > 64-@@ cygpath -w /drv/e > > E:\ > > > 64-@@ mkdir 'e:\' # creates subdirectory e: !!!!! > > 64-@@ rmdir 'e:\' # fails, because it refers to /drv/e > > rmdir: failed to remove 'e:\': Directory not empty > > > 64-@@ rmdir 'e:' > > > 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. > > > Any reason for this remarkable difference? > > 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). .. uhm, I must be speaking to the alter ego of Corinna V,. because as far as I know, Corinna has given herself some time off ... Perhaps you could make an entry in her "TODO list" that the 3 lines above requires some more explanation for pour souls like me. No, there is no hurry ... 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ... 2019-08-27 17:01 ` Houder @ 2019-08-27 17:32 ` Vince Rice 2019-08-27 17:50 ` Corinna Vinschen 2019-08-28 7:16 ` Houder 0 siblings, 2 replies; 32+ messages in thread From: Vince Rice @ 2019-08-27 17:32 UTC (permalink / raw) To: cygwin > On Aug 27, 2019, at 11:28 AM, Houder wrote: > > On Tue, 27 Aug 2019 17:25:49, 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). > > .. uhm, I must be speaking to the alter ego of Corinna V,. because > as far as I know, Corinna has given herself some time off ... > > Perhaps you could make an entry in her "TODO list" that the 3 lines > above requires some more explanation for pour souls like me. I am not Corinna, but I read that as… The mkdir command works because it has special code added to it to make it work. The rmdir command doesn't work because it doesn't have the same code in it. -- 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ... 2019-08-27 17:32 ` Vince Rice @ 2019-08-27 17:50 ` Corinna Vinschen 2019-08-28 7:16 ` Houder 1 sibling, 0 replies; 32+ messages in thread From: Corinna Vinschen @ 2019-08-27 17:50 UTC (permalink / raw) To: Vince Rice; +Cc: cygwin [-- Attachment #1: Type: text/plain, Size: 909 bytes --] On Aug 27 11:44, Vince Rice wrote: > > On Aug 27, 2019, at 11:28 AM, Houder wrote: > > > > On Tue, 27 Aug 2019 17:25:49, 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). > > > > .. uhm, I must be speaking to the alter ego of Corinna V,. because > > as far as I know, Corinna has given herself some time off ... Back for a couple days only :} > > Perhaps you could make an entry in her "TODO list" that the 3 lines > > above requires some more explanation for pour souls like me. > > I am not Corinna, but I read that as… > The mkdir command works because it has special code added to it to make > it work. The rmdir command doesn't work because it doesn't have the same > code in it. Exactly. Corinna [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ... 2019-08-27 17:32 ` Vince Rice 2019-08-27 17:50 ` Corinna Vinschen @ 2019-08-28 7:16 ` Houder 2019-08-28 9:22 ` john doe 2019-08-28 13:22 ` Corinna Vinschen 1 sibling, 2 replies; 32+ messages in thread From: Houder @ 2019-08-28 7:16 UTC (permalink / raw) To: cygwin On Tue, 27 Aug 2019 11:44:17, Vince Rice wrote: > > On Aug 27, 2019, at 11:28 AM, Houder wrote: > > > > On Tue, 27 Aug 2019 17:25:49, 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). > > > > .. uhm, I must be speaking to the alter ego of Corinna V,. because > > as far as I know, Corinna has given herself some time off ... > > > > Perhaps you could make an entry in her "TODO list" that the 3 lines > > above requires some more explanation for pour souls like me. > > I am not Corinna, but I read that as > The mkdir command works because it has special code added to it to make > it work. The rmdir command doesn't work because it doesn't have the same > code in it. Right, "Corinna" Number Three. Before I sent my question to the list, I had fired up the debugger and lured it in providing me the neccessary info: It showed me that my input (e:\) was being "mutilated" at the start of mkdir() in winsup/cygwin/dir.cc Using git I had found the "suspicious-looking" commit by Eric Blake: - https://cygwin.com/git/gitweb.cgi?p=newlib-cygwin.git;a=commit;h=52dba6a5c45e8d8ba1e237a15213311dc11d91fb ( Fix some POSIX-compliance bugs in link, rename, mkdir. ) -- author Eric Blake <eblake@redhat.com> Sat, 26 Sep 2009 15:51:53 +0000 (15:51 +0000) <==== committer Eric Blake <eblake@redhat.com> Sat, 26 Sep 2009 15:51:53 +0000 (15:51 +0000) commit 52dba6a5c45e8d8ba1e237a15213311dc11d91fb -- Note September 2009! (as hinted by Corinna's alter ego) In short, neither the answer by Corinna's alter ego nor your translation raised the level of the knowledge that I had already acquired. Linux-compat. Really? Who in his right mind would want to create a subdirectory e:\ on Linux? ls -ld 'e:\' stat 'e:\' touch 'e:\' rmdir 'e:\' all refer to /drv/e # /cygdrive/e if not remapped Only mkdir does NOT. And I am the only one who finds this a bit odd? That why I asked: why cannot mkdir and rmdir be symmetrical w/ respect to e:\ ? Because of Linux? Weird. Now I have to tell a newbie on Cygwin, that he should use mkdir 'e:\.' BUT rmdir 'e:\' in order to observe the same results as the Windows equivalents do. (yes, he should use mkdir /drv/e and rmdir /drv/e) Tampi. Apparently, design decisions in Cygwin must remain in the mists of the past. Like archeology cannot tell us how our forefathers lived in the Netherlands some three milleniums ago (The Netherlands were flooded several times in the past : all info has gone as result of that). 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ... 2019-08-28 7:16 ` Houder @ 2019-08-28 9:22 ` john doe 2019-08-28 11:47 ` Houder 2019-08-28 13:22 ` Corinna Vinschen 1 sibling, 1 reply; 32+ messages in thread From: john doe @ 2019-08-28 9:22 UTC (permalink / raw) To: cygwin On 8/28/2019 9:16 AM, Houder wrote: > On Tue, 27 Aug 2019 11:44:17, Vince Rice wrote: > >>> On Aug 27, 2019, at 11:28 AM, Houder wrote: >>> >>> On Tue, 27 Aug 2019 17:25:49, 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). >>> >>> .. uhm, I must be speaking to the alter ego of Corinna V,. because >>> as far as I know, Corinna has given herself some time off ... >>> >>> Perhaps you could make an entry in her "TODO list" that the 3 lines >>> above requires some more explanation for pour souls like me. >> >> I am not Corinna, but I read that as >> The mkdir command works because it has special code added to it to make >> it work. The rmdir command doesn't work because it doesn't have the same >> code in it. > > Right, "Corinna" Number Three. > > Before I sent my question to the list, I had fired up the debugger and > lured it in providing me the neccessary info: > > It showed me that my input (e:\) was being "mutilated" at the start of > mkdir() in winsup/cygwin/dir.cc > > Using git I had found the "suspicious-looking" commit by Eric Blake: > > - https://cygwin.com/git/gitweb.cgi?p=newlib-cygwin.git;a=commit;h=52dba6a5c45e8d8ba1e237a15213311dc11d91fb > ( Fix some POSIX-compliance bugs in link, rename, mkdir. ) > > -- > author Eric Blake <eblake@redhat.com> > Sat, 26 Sep 2009 15:51:53 +0000 (15:51 +0000) <==== > committer Eric Blake <eblake@redhat.com> > Sat, 26 Sep 2009 15:51:53 +0000 (15:51 +0000) > commit 52dba6a5c45e8d8ba1e237a15213311dc11d91fb > -- > > Note September 2009! (as hinted by Corinna's alter ego) > > In short, neither the answer by Corinna's alter ego nor your translation > raised the level of the knowledge that I had already acquired. > > Linux-compat. Really? > > Who in his right mind would want to create a subdirectory e:\ on Linux? > > ls -ld 'e:\' > stat 'e:\' > touch 'e:\' > rmdir 'e:\' > > all refer to /drv/e # /cygdrive/e if not remapped > > Only mkdir does NOT. > > And I am the only one who finds this a bit odd? That why I asked: why > cannot mkdir and rmdir be symmetrical w/ respect to e:\ ? > > Because of Linux? Weird. > > Now I have to tell a newbie on Cygwin, that he should use > > mkdir 'e:\.' BUT rmdir 'e:\' > > in order to observe the same results as the Windows equivalents do. > > (yes, he should use mkdir /drv/e and rmdir /drv/e) > > Tampi. > As hinted out in here, backporting the code snippet from mkdir to rmdir would solve your issue. -- John Doe -- 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ... 2019-08-28 9:22 ` john doe @ 2019-08-28 11:47 ` Houder 0 siblings, 0 replies; 32+ messages in thread From: Houder @ 2019-08-28 11:47 UTC (permalink / raw) To: cygwin On Wed, 28 Aug 2019 10:32:27, john doe wrote: > As hinted out in here, backporting the code snippet from mkdir to rmdir > would solve your issue. No, the reverse. Removing the snippet from mkdir() would solve my issue. rmdir() does the right thing; currently, mkdir() does the wrong thing. 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ... 2019-08-28 7:16 ` Houder 2019-08-28 9:22 ` john doe @ 2019-08-28 13:22 ` Corinna Vinschen 2019-08-28 14:16 ` Eric Blake 1 sibling, 1 reply; 32+ messages in thread From: Corinna Vinschen @ 2019-08-28 13:22 UTC (permalink / raw) To: Eric Blake; +Cc: cygwin [-- Attachment #1: Type: text/plain, Size: 2225 bytes --] On Aug 28 09:16, Houder wrote: > On Tue, 27 Aug 2019 11:44:17, Vince Rice wrote: > > > > On Aug 27, 2019, at 11:28 AM, Houder wrote: > > > > > > On Tue, 27 Aug 2019 17:25:49, 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). > > > > > > .. uhm, I must be speaking to the alter ego of Corinna V,. because > > > as far as I know, Corinna has given herself some time off ... > > > > > > Perhaps you could make an entry in her "TODO list" that the 3 lines > > > above requires some more explanation for pour souls like me. > > > > I am not Corinna, but I read that as > > The mkdir command works because it has special code added to it to make > > it work. The rmdir command doesn't work because it doesn't have the same > > code in it. > > Right, "Corinna" Number Three. > > Before I sent my question to the list, I had fired up the debugger and > lured it in providing me the neccessary info: > > It showed me that my input (e:\) was being "mutilated" at the start of > mkdir() in winsup/cygwin/dir.cc > > Using git I had found the "suspicious-looking" commit by Eric Blake: > > - https://cygwin.com/git/gitweb.cgi?p=newlib-cygwin.git;a=commit;h=52dba6a5c45e8d8ba1e237a15213311dc11d91fb > ( Fix some POSIX-compliance bugs in link, rename, mkdir. ) > > -- > author Eric Blake <eblake@redhat.com> > Sat, 26 Sep 2009 15:51:53 +0000 (15:51 +0000) <==== > committer Eric Blake <eblake@redhat.com> > Sat, 26 Sep 2009 15:51:53 +0000 (15:51 +0000) > commit 52dba6a5c45e8d8ba1e237a15213311dc11d91fb > -- > > Note September 2009! (as hinted by Corinna's alter ego) 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. 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. Corinna -- Corinna Vinschen Cygwin Maintainer [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ... 2019-08-28 13:22 ` Corinna Vinschen @ 2019-08-28 14:16 ` Eric Blake 2019-08-28 14:22 ` Corinna Vinschen 0 siblings, 1 reply; 32+ messages in thread From: Eric Blake @ 2019-08-28 14:16 UTC (permalink / raw) To: cygwin [-- Attachment #1.1: Type: text/plain, Size: 1426 bytes --] 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). > > 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 '\'). > > 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. > > > Corinna > -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ... 2019-08-28 14:16 ` Eric Blake @ 2019-08-28 14:22 ` Corinna Vinschen 2019-08-28 15:18 ` Corinna Vinschen 0 siblings, 1 reply; 32+ messages in thread From: Corinna Vinschen @ 2019-08-28 14:22 UTC (permalink / raw) To: Eric Blake; +Cc: cygwin [-- Attachment #1: Type: text/plain, Size: 1882 bytes --] On Aug 28 08:36, Eric Blake wrote: > 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). > > > > > > 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 '\'). As simple as that? diff --git a/winsup/cygwin/dir.cc b/winsup/cygwin/dir.cc index b757851d5c7f..747b1582af50 100644 --- a/winsup/cygwin/dir.cc +++ b/winsup/cygwin/dir.cc @@ -314,13 +314,13 @@ mkdir (const char *dir, mode_t mode) set_errno (ENOENT); __leave; } - if (isdirsep (dir[strlen (dir) - 1])) + if (dir[strlen (dir) - 1] == '/') { /* This converts // to /, but since both give EEXIST, we're okay. */ char *buf; char *p = stpcpy (buf = tp.c_get (), dir) - 1; dir = buf; - while (p > dir && isdirsep (*p)) + while (p > dir && *p == '/') *p-- = '\0'; } if (!(fh = build_fh_name (dir, PC_SYM_NOFOLLOW))) Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ... 2019-08-28 14:22 ` Corinna Vinschen @ 2019-08-28 15:18 ` Corinna Vinschen 2019-08-29 15:19 ` Houder 2019-09-07 3:47 ` L A Walsh 0 siblings, 2 replies; 32+ messages in thread From: Corinna Vinschen @ 2019-08-28 15:18 UTC (permalink / raw) To: Eric Blake; +Cc: cygwin [-- Attachment #1: Type: text/plain, Size: 2268 bytes --] On Aug 28 16:15, Corinna Vinschen wrote: > On Aug 28 08:36, Eric Blake wrote: > > 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). > > > > > > > > > > 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 '\'). > > As simple as that? > > diff --git a/winsup/cygwin/dir.cc b/winsup/cygwin/dir.cc > index b757851d5c7f..747b1582af50 100644 > --- a/winsup/cygwin/dir.cc > +++ b/winsup/cygwin/dir.cc > @@ -314,13 +314,13 @@ mkdir (const char *dir, mode_t mode) > set_errno (ENOENT); > __leave; > } > - if (isdirsep (dir[strlen (dir) - 1])) > + if (dir[strlen (dir) - 1] == '/') > { > /* This converts // to /, but since both give EEXIST, we're okay. */ > char *buf; > char *p = stpcpy (buf = tp.c_get (), dir) - 1; > dir = buf; > - while (p > dir && isdirsep (*p)) > + while (p > dir && *p == '/') > *p-- = '\0'; > } > if (!(fh = build_fh_name (dir, PC_SYM_NOFOLLOW))) One problem here is, what to do about border cases like $ mkdir a\/\/\/ In theory slashes and backslashes should both be treated as dir separators. Handling a case like this so that all expectations are satisfied is next to impossible, I guess. Corinna -- Corinna Vinschen Cygwin Maintainer [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ... 2019-08-28 15:18 ` Corinna Vinschen @ 2019-08-29 15:19 ` Houder 2019-08-30 8:20 ` Corinna Vinschen 2019-08-30 12:42 ` Houder 2019-09-07 3:47 ` L A Walsh 1 sibling, 2 replies; 32+ messages in thread From: Houder @ 2019-08-29 15:19 UTC (permalink / raw) To: cygwin On Wed, 28 Aug 2019 16:22:20, Corinna Vinschen wrote: > > As simple as that? > > > > diff --git a/winsup/cygwin/dir.cc b/winsup/cygwin/dir.cc > > index b757851d5c7f..747b1582af50 100644 > > --- a/winsup/cygwin/dir.cc > > +++ b/winsup/cygwin/dir.cc > > @@ -314,13 +314,13 @@ mkdir (const char *dir, mode_t mode) > > set_errno (ENOENT); > > __leave; > > } > > - if (isdirsep (dir[strlen (dir) - 1])) > > + if (dir[strlen (dir) - 1] =3D=3D '/') > > { > > /* This converts // to /, but since both give EEXIST, we're okay. */ > > char *buf; > > char *p =3D stpcpy (buf =3D tp.c_get (), dir) - 1; > > dir =3D buf; > > - while (p > dir && isdirsep (*p)) > > + while (p > dir && *p =3D=3D '/') > > *p-- =3D '\0'; > > } > > if (!(fh =3D build_fh_name (dir, PC_SYM_NOFOLLOW))) > > One problem here is, what to do about border cases like > > $ mkdir a\/\/\/ > > In theory slashes and backslashes should both be treated as dir > separators. Handling a case like this so that all expectations > are satisfied is next to impossible, I guess. How about dropping Eric's code snippet in winsup/cygwin/dir.cc ????? Subdirectory 'a' is created. No problem there. Perhaps the patch has become superfluous/ redundant over time? I have tried different "values" for the path-argument to mkdir, and have not found a problem while the code snippet is being skipped. What am I missing? Henri ----- Breakpoint 1 at 0x1800548b9: file /usr/src/debug/cygwin-3.1.0-0.2/winsup/cygwin/dir.cc, line 317. Breakpoint 2 at 0x1800548e3: file /usr/src/debug/cygwin-3.1.0-0.2/winsup/cygwin/dir.cc, line 326. (gdb) r Starting program: /usr/bin/mkdir 'a\/\/\/' [New Thread 1064.0x1a8c] [New Thread 1064.0x59c] Thread 1 "mkdir" hit Breakpoint 1, mkdir (dir=0x800041320 "a\\/\\/\\/", mode=511) at /usr/src/debug/cygwin-3.1.0-0.2/winsup/cygwin/dir.cc:317 317 if (isdirsep (dir[strlen (dir) - 1])) (gdb) j dir.cc:326 Continuing at 0x1800548e3. Thread 1 "mkdir" hit Breakpoint 2, mkdir (dir=0x800041320 "a\\/\\/\\/", mode=511) at /usr/src/debug/cygwin-3.1.0-0.2/winsup/cygwin/dir.cc:326 326 if (!(fh = build_fh_name (dir, PC_SYM_NOFOLLOW))) (gdb) c Continuing. [Inferior 1 (process 1064) exited normally] (gdb) quit 64-@@ ls -ld a* drwxr-xr-x+ 1 Henri None 0 Aug 29 16:47 a ===== -- 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ... 2019-08-29 15:19 ` Houder @ 2019-08-30 8:20 ` Corinna Vinschen 2019-08-30 12:42 ` Houder 1 sibling, 0 replies; 32+ messages in thread From: Corinna Vinschen @ 2019-08-30 8:20 UTC (permalink / raw) To: cygwin; +Cc: Eric Blake [-- Attachment #1: Type: text/plain, Size: 2879 bytes --] Eric? On Aug 29 17:05, Houder wrote: > On Wed, 28 Aug 2019 16:22:20, Corinna Vinschen wrote: > > > > As simple as that? > > > > > > diff --git a/winsup/cygwin/dir.cc b/winsup/cygwin/dir.cc > > > index b757851d5c7f..747b1582af50 100644 > > > --- a/winsup/cygwin/dir.cc > > > +++ b/winsup/cygwin/dir.cc > > > @@ -314,13 +314,13 @@ mkdir (const char *dir, mode_t mode) > > > set_errno (ENOENT); > > > __leave; > > > } > > > - if (isdirsep (dir[strlen (dir) - 1])) > > > + if (dir[strlen (dir) - 1] =3D=3D '/') > > > { > > > /* This converts // to /, but since both give EEXIST, we're okay. */ > > > char *buf; > > > char *p =3D stpcpy (buf =3D tp.c_get (), dir) - 1; > > > dir =3D buf; > > > - while (p > dir && isdirsep (*p)) > > > + while (p > dir && *p =3D=3D '/') > > > *p-- =3D '\0'; > > > } > > > if (!(fh =3D build_fh_name (dir, PC_SYM_NOFOLLOW))) > > > > One problem here is, what to do about border cases like > > > > $ mkdir a\/\/\/ > > > > In theory slashes and backslashes should both be treated as dir > > separators. Handling a case like this so that all expectations > > are satisfied is next to impossible, I guess. > > How about dropping Eric's code snippet in winsup/cygwin/dir.cc ????? > > Subdirectory 'a' is created. No problem there. Perhaps the patch has > become superfluous/ redundant over time? > > I have tried different "values" for the path-argument to mkdir, and > have not found a problem while the code snippet is being skipped. > > What am I missing? > > Henri > > ----- > Breakpoint 1 at 0x1800548b9: file /usr/src/debug/cygwin-3.1.0-0.2/winsup/cygwin/dir.cc, line 317. > Breakpoint 2 at 0x1800548e3: file /usr/src/debug/cygwin-3.1.0-0.2/winsup/cygwin/dir.cc, line 326. > (gdb) r > Starting program: /usr/bin/mkdir 'a\/\/\/' > [New Thread 1064.0x1a8c] > [New Thread 1064.0x59c] > > Thread 1 "mkdir" hit Breakpoint 1, mkdir (dir=0x800041320 "a\\/\\/\\/", mode=511) > at /usr/src/debug/cygwin-3.1.0-0.2/winsup/cygwin/dir.cc:317 > 317 if (isdirsep (dir[strlen (dir) - 1])) > (gdb) j dir.cc:326 > Continuing at 0x1800548e3. > > Thread 1 "mkdir" hit Breakpoint 2, mkdir (dir=0x800041320 "a\\/\\/\\/", mode=511) > at /usr/src/debug/cygwin-3.1.0-0.2/winsup/cygwin/dir.cc:326 > 326 if (!(fh = build_fh_name (dir, PC_SYM_NOFOLLOW))) > (gdb) c > Continuing. > [Inferior 1 (process 1064) exited normally] > (gdb) quit > > 64-@@ ls -ld a* > drwxr-xr-x+ 1 Henri None 0 Aug 29 16:47 a > > ===== > > > -- > 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 -- Corinna Vinschen Cygwin Maintainer [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ... 2019-08-29 15:19 ` Houder 2019-08-30 8:20 ` Corinna Vinschen @ 2019-08-30 12:42 ` Houder 2019-09-01 17:38 ` Houder 1 sibling, 1 reply; 32+ messages in thread From: Houder @ 2019-08-30 12:42 UTC (permalink / raw) To: cygwin; +Cc: eblake On Thu, 29 Aug 2019 17:05:41, Houder wrote: > On Wed, 28 Aug 2019 16:22:20, Corinna Vinschen wrote: [snip] > > One problem here is, what to do about border cases like > > > > $ mkdir a\/\/\/ > > > > In theory slashes and backslashes should both be treated as dir > > separators. Handling a case like this so that all expectations > > are satisfied is next to impossible, I guess. > > How about dropping Eric's code snippet in winsup/cygwin/dir.cc ????? > > Subdirectory 'a' is created. No problem there. Perhaps the patch has > become superfluous/ redundant over time? > > I have tried different "values" for the path-argument to mkdir, and > have not found a problem while the code snippet is being skipped. > > What am I missing? A trailing forward slash in "pathname" is stripped in path_conv::check, (look for: *--tail = '\0' ) after "pathname" has been normalized in normalized_posix_path or normalized_win32_path (or both), before it is fed into conv_to_win32_path. Tests have shown that Eric's code snippet can be deleted w/o harm. Counter arguments? Henri > ----- > Breakpoint 1 at 0x1800548b9: file /usr/src/debug/cygwin-3.1.0-0.2/winsup/cygwin/dir.cc, line 317. > Breakpoint 2 at 0x1800548e3: file /usr/src/debug/cygwin-3.1.0-0.2/winsup/cygwin/dir.cc, line 326. > (gdb) r > Starting program: /usr/bin/mkdir 'a\/\/\/' > [New Thread 1064.0x1a8c] > [New Thread 1064.0x59c] > > Thread 1 "mkdir" hit Breakpoint 1, mkdir (dir=0x800041320 "a\\/\\/\\/", mode=511) > at /usr/src/debug/cygwin-3.1.0-0.2/winsup/cygwin/dir.cc:317 > 317 if (isdirsep (dir[strlen (dir) - 1])) > (gdb) j dir.cc:326 > Continuing at 0x1800548e3. > > Thread 1 "mkdir" hit Breakpoint 2, mkdir (dir=0x800041320 "a\\/\\/\\/", mode=511) > at /usr/src/debug/cygwin-3.1.0-0.2/winsup/cygwin/dir.cc:326 > 326 if (!(fh = build_fh_name (dir, PC_SYM_NOFOLLOW))) > (gdb) c > Continuing. > [Inferior 1 (process 1064) exited normally] > (gdb) quit > > 64-@@ ls -ld a* > drwxr-xr-x+ 1 Henri None 0 Aug 29 16:47 a > > ===== -- 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ... 2019-08-30 12:42 ` Houder @ 2019-09-01 17:38 ` Houder 2019-09-02 8:15 ` Corinna Vinschen ` (2 more replies) 0 siblings, 3 replies; 32+ messages in thread From: Houder @ 2019-09-01 17:38 UTC (permalink / raw) To: cygwin; +Cc: eblake On Fri, 30 Aug 2019 11:54:27, Houder wrote: > A trailing forward slash in "pathname" is stripped in path_conv::check, > > (look for: *--tail = '\0' ) > > after "pathname" has been normalized in > > normalized_posix_path or normalized_win32_path (or both), > > before it is fed into conv_to_win32_path. > > Tests have shown that Eric's code snippet can be deleted w/o harm. > > Counter arguments? Hi Corinna, My last post in this issue. As reported, Eric's code snippet in rmdir() (dir.cc) has become redundant, lines 317 - 325 can be removed. https://cygwin.com/ml/cygwin/2019-08/msg00418.html My "rough" understanding of the code flow is as follows: mkdir in dir.cc fh = build_fh_name -- returns pointer to fhandler_base build_fh_pc fh->mkdir(mode) -- handled by mkdir() in fhandler_disk_file.cc NtCreateFile(... FILE_ATTRIBUTE_DIRECTORY ...) fhandler_base has a member of type path_conv, called pc, which is a copy of the path_conv object, created by build_fh_name(). Having removed Eric's code snippet in dir.cc - and for the sake of completeness, I decided to inspect the values of pc.posix_path and pc.path (i.e. "pathname" in native format) when I stopped the debugger in mkdir() (fhandler_disk_file.cc). If I specified e.g. '/foo/\/' as the directory to create, I saw the following: pc.path = "E:\\Cygwin64\\foo" pc.posix_path = "/" <==== HUH? As the directory "/foo" had been correctly created, I turned to path_conv::check(), which is called when build_fhname() creates the path_conv object (also called pc) -- see dtable.cc. Examining this (obsure) method in path.cc, I corrected the code in 2 places: --- if (dev.isfs ()) { //if (strncmp (path, "\\\\.\\", 4)) <==== 1171 if ( ! strncmp (path, "\\\\.\\", 4)) // <==== [1] { if (!tail || tail == path) /* nothing */; else if (tail[-1] != '\\') *tail = '\0'; <==== Ah! (you should not do that!) else { error = ENOENT; return; } } [1] this code should be executed only if path == '\\.\' !! The above snippet 'mutilated' "/foo" into "/\0oo" --- //else if (!need_directory || error) <==== 1155 else if (!need_directory || error || (opt & PC_SYM_NOFOLLOW) ) /* nothing to do */; else if (fileattr == INVALID_FILE_ATTRIBUTES) /* Reattach trailing dirsep in native path. */ strcat (modifiable_path (), "\\"); // <==== [2] [2] WHY? Why must the native name of a directory be terminated by a backslash? (NtCreateFile() specifies that a directory must be created -- see mkdir() in fhandler_disk_file.c). Yes, the above correction is an awfull hack (it abuses the Posix directive that _no_ directory shall be created through a symbolic link). Without this hack, a directory specified as '/foo/' will result in pc.path = "E:\\Cygwin64\foo\" <==== note additional \ pc.posix_path = "/foo" Without the corrections in path_conv::check() (and without Eric's code snippet in dir.cc), a directory will be correctly created. However, pc.path and pc.posix_path will not always be "equal", i.e. consistent w/ each other. Regards, 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ... 2019-09-01 17:38 ` Houder @ 2019-09-02 8:15 ` Corinna Vinschen 2019-09-03 8:40 ` Houder 2019-09-03 6:50 ` Andrey Repin 2019-09-19 19:51 ` Ken Brown 2 siblings, 1 reply; 32+ messages in thread From: Corinna Vinschen @ 2019-09-02 8:15 UTC (permalink / raw) To: Houder; +Cc: cygwin, eblake [-- Attachment #1: Type: text/plain, Size: 981 bytes --] On Sep 1 19:38, Houder wrote: > On Fri, 30 Aug 2019 11:54:27, Houder wrote: > > > A trailing forward slash in "pathname" is stripped in path_conv::check, > > > > (look for: *--tail = '\0' ) > > > > after "pathname" has been normalized in > > > > normalized_posix_path or normalized_win32_path (or both), > > > > before it is fed into conv_to_win32_path. > > > > Tests have shown that Eric's code snippet can be deleted w/o harm. > > > > Counter arguments? > > Hi Corinna, > > My last post in this issue. > > As reported, Eric's code snippet in rmdir() (dir.cc) has become > redundant, lines 317 - 325 can be removed. This is what I'm not entirely sure about. There's some kind of bordercase and as soon as we release Cygwin with this change, as chance would have it somebody will report a problem. I'm not opposed to removing this code, but I'd like to get Eric's input on this. Corinna -- Corinna Vinschen Cygwin Maintainer [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ... 2019-09-02 8:15 ` Corinna Vinschen @ 2019-09-03 8:40 ` Houder 0 siblings, 0 replies; 32+ messages in thread From: Houder @ 2019-09-03 8:40 UTC (permalink / raw) To: cygwin On Mon, 2 Sep 2019 10:15:08, Corinna Vinschen wrote: > > On Sep 1 19:38, Houder wrote: > > Hi Corinna, > > > > My last post in this issue. > > > > As reported, Eric's code snippet in rmdir() (dir.cc) has become > > redundant, lines 317 - 325 can be removed. > > This is what I'm not entirely sure about. There's some kind of > bordercase and as soon as we release Cygwin with this change, > as chance would have it somebody will report a problem. And you would be correct ... :-P (see below) > I'm not opposed to removing this code, but I'd like to get Eric's > input on this. Sure, I understand (Eric is far more knowledgable than I am). Henri ----- 64-@@ uname -a CYGWIN_NT-6.1 Seven 3.1.0 path.cc-!opt (2019-09-02 15:11 2019-09-02 15:11 x86_64 Cygwin ------------ That is, I am using an modified 3.1.0-0.2 ... 64-@@ mkdir aap 64-@@ ln -s aap noot 64-@@ mkdir noot mkdir: cannot create directory ânootâ: File exists 64-@@ mkdir noot/ mkdir: cannot create directory ânoot/â: File exists 64-@@ rmdir aap 64-@@ mkdir noot mkdir: cannot create directory ânootâ: File exists 64-@@ mkdir noot/ <==== Whao! So that is what Eric indicated in his commit! 64-@@ ls -ld aap <==== WRONG! WRONG! drwxr-xr-x+ 1 Henri None 0 Sep 3 10:28 aap Investigating ... ===== -- 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ... 2019-09-01 17:38 ` Houder 2019-09-02 8:15 ` Corinna Vinschen @ 2019-09-03 6:50 ` Andrey Repin 2019-09-19 19:51 ` Ken Brown 2 siblings, 0 replies; 32+ messages in thread From: Andrey Repin @ 2019-09-03 6:50 UTC (permalink / raw) To: Houder, cygwin Greetings, Houder! > Examining this (obsure) method in path.cc, I corrected the code > in 2 places: > --- > if (dev.isfs ()) > { > //if (strncmp (path, "\\\\.\\", 4)) <==== 1171 > if ( ! strncmp (path, "\\\\.\\", 4)) // <==== [1] > { > if (!tail || tail == path) > /* nothing */; > else if (tail[-1] != '\\') > *tail = '\0'; <==== Ah! (you should not do that!) > else > { > error = ENOENT; > return; > } > } > [1] this code should be executed only if path == '\\.\' !! "\\.\" is an UNC reference to "this host". Used f.e. in references to Windows "named pipes". -- With best regards, Andrey Repin Tuesday, September 3, 2019 9:46:42 Sorry for my terrible english... -- 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ... 2019-09-01 17:38 ` Houder 2019-09-02 8:15 ` Corinna Vinschen 2019-09-03 6:50 ` Andrey Repin @ 2019-09-19 19:51 ` Ken Brown 2019-09-20 9:11 ` Houder 2 siblings, 1 reply; 32+ messages in thread From: Ken Brown @ 2019-09-19 19:51 UTC (permalink / raw) To: cygwin On 9/1/2019 1:38 PM, Houder wrote: > On Fri, 30 Aug 2019 11:54:27, Houder wrote: [...] > As the directory "/foo" had been correctly created, I turned to > path_conv::check(), which is called when build_fhname() creates > the path_conv object (also called pc) -- see dtable.cc. > > Examining this (obsure) method in path.cc, I corrected the code > in 2 places: > > --- > if (dev.isfs ()) > { > //if (strncmp (path, "\\\\.\\", 4)) <==== 1171 > if ( ! strncmp (path, "\\\\.\\", 4)) // <==== [1] > { > if (!tail || tail == path) > /* nothing */; > else if (tail[-1] != '\\') > *tail = '\0'; <==== Ah! (you should not do that!) > else > { > error = ENOENT; > return; > } > } > > [1] this code should be executed only if path == '\\.\' !! I don't agree with your analysis here. First, the strncmp() call is testing whether path *starts with* '\\.\', not whether path == '\\.\'. For example, path might be a UNC device name like '\\.\c:'. Second, as the original code indicates (before your correction), we do *not* want to execute the code in that case, since we might be mutilating the device name or incorrectly setting ENOENT. On the other hand, I agree that there's something wrong with that code snippet. Comparing tail with path [which is the class member this->path] makes no sense here, because tail is a pointer into path_copy. So I think line 1173 should read if (!tail || tail == path_copy) If this condition fails, then it's legitimate to refer to tail[-1] two lines later. Observe next that path_copy contains no backslashes, so I think line 1175 should probably be else if (tail[-1] != '/') I don't immediately see why we would then set *tail = '\0' in this case, because I think *tail is already 0 if we get here and tail[-1] != '/'. But maybe I'm missing something. I need to think about this further, but I wanted to write down my initial thoughts before your bug report gets forgotten. To be continued. Ken -- 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ... 2019-09-19 19:51 ` Ken Brown @ 2019-09-20 9:11 ` Houder 2019-09-20 18:20 ` Houder 0 siblings, 1 reply; 32+ messages in thread From: Houder @ 2019-09-20 9:11 UTC (permalink / raw) To: cygwin On Thu, 19 Sep 2019 18:04:47, Ken Brown wrote: > On 9/1/2019 1:38 PM, Houder wrote: > > On Fri, 30 Aug 2019 11:54:27, Houder wrote: > > [...] > > > As the directory "/foo" had been correctly created, I turned to > > path_conv::check(), which is called when build_fhname() creates > > the path_conv object (also called pc) -- see dtable.cc. > > > > Examining this (obsure) method in path.cc, I corrected the code > > in 2 places: > > > > --- > > if (dev.isfs ()) > > { > > //if (strncmp (path, "\\\\.\\", 4)) <==== 1171 > > if ( ! strncmp (path, "\\\\.\\", 4)) // <==== [1] > > { > > if (!tail || tail == path) > > /* nothing */; > > else if (tail[-1] != '\\') > > *tail = '\0'; <==== Ah! (you should not do that!) > > else > > { > > error = ENOENT; > > return; > > } > > } > > > > [1] this code should be executed only if path == '\\.\' !! Sorry Ken, for not being correct ... Of course, the statement above tests whether or not the string *** starts with *** \\.\ > I don't agree with your analysis here. Analysis of what? No Ken, I did not _analyze_ what this piece of code is good for. I only discovered that it "mutilates" the code if one exexutes mkdir /foo, where foo is a nonexisting directory So, in general this piece of code should NOT be executed. And I doubt if it is ever reached in case of a device path, like \\.\e: (did not check). Btw, do not pay attention to the second correction (hack) that I made in this method; I dropped it. That said, my modifications to mkdir_2 and rmdir_2 are more relevant. Currently, rmdir_2 is not in agreement with Posix (and Linux). Currently I am running the modified code (including the above correction in "path resolution" -- i.c. path_conv::check). Found no problems. And my tests show that rmdir_2 is now in agreement w/ Posix (and Linux). Oh sorry, mkdir_2 and rmdir_2 should be read as mkdir(2) and rmdir(2). (the syscalls in dir.cc, not the functions in fhandler_disk_file.cc) 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ... 2019-09-20 9:11 ` Houder @ 2019-09-20 18:20 ` Houder 2019-09-21 16:07 ` Ken Brown 0 siblings, 1 reply; 32+ messages in thread From: Houder @ 2019-09-20 18:20 UTC (permalink / raw) To: cygwin On Fri, 20 Sep 2019 09:55:59, Houder wrote: [snip] > So, in general this piece of code should NOT be executed. And I doubt if > it is ever reached in case of a device path, like \\.\e: (did not check). Did check. Using my modified code (and debugger). Yes, the code snippet is reached in case of \\.\e: However it acts as a no-opt in that case. 64-@@ stat '\\.\e:' File: \\.\e: Size: 219 Blocks: 6294892 IO Block: 65536 regular file Device: c3h/195d Inode: 264012044752017013 Links: 0 Access: (0644/-rw-r--r--) Uid: ( 1000/ Henri) Gid: ( 513/ None) Access: 16517-07-08 10:41:04.823790000 +0200 Modify: 24765-07-23 04:41:36.216813500 +0200 Change: 27044-04-14 13:59:54.642955700 +0200 Birth: - 64-@@ stat '\\.\e:\' stat: cannot stat '\\.\e:\': Not a directory As I said already, the snippet should NOT be executed in general. Perhaps it is another left-over from old times that should have been deleted. 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ... 2019-09-20 18:20 ` Houder @ 2019-09-21 16:07 ` Ken Brown 2019-09-22 7:34 ` Houder 0 siblings, 1 reply; 32+ messages in thread From: Ken Brown @ 2019-09-21 16:07 UTC (permalink / raw) To: cygwin On 9/20/2019 5:11 AM, Houder wrote: > As I said already, the snippet should NOT be executed in general. Perhaps > it is another left-over from old times that should have been deleted. You're absolutely right. Prior to commit b0717aae0, the code looked like this: if (strncmp (path, "\\\\.\\", 4)) { /* Windows ignores trailing dots and spaces in the last path component, and ignores exactly one trailing dot in inner path components. */ char *tail = NULL; [...] if (!tail || tail == path) /* nothing */; else if (tail[-1] != '\\') { *tail = '\0'; strip_tail = true; } else { error = ENOENT; return; } } Note the use of a *local* tail variable. It's a pointer into path, as you can see by looking at the part I omitted. In commit b0717aae0, Corinna intended to disable this code, but she inadvertently disabled only part of it. Here's the relevant part of that commit: @@ -1170,6 +1225,7 @@ out: { if (strncmp (path, "\\\\.\\", 4)) { +#if 0 /* Windows ignores trailing dots and spaces in the last path component, and ignores exactly one trailing dot in inner path components. */ @@ -1190,7 +1246,7 @@ out: tail = NULL; } } - +#endif if (!tail || tail == path) /* nothing */; else if (tail[-1] != '\\') In particular, the declaration of the local tail variable is in the disabled code, so the cruft at the end is referring to the other tail, which points into path_copy. [A later commit removed the disabled code.] I'll fix this and then look at your patches to mkdir and rmdir. It would be very helpful if you would write these as a patch series with cover letter, using git format-patch, and send them to the cygwin-patches list. Ken -- 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ... 2019-09-21 16:07 ` Ken Brown @ 2019-09-22 7:34 ` Houder 2019-09-22 14:12 ` Ken Brown 0 siblings, 1 reply; 32+ messages in thread From: Houder @ 2019-09-22 7:34 UTC (permalink / raw) To: cygwin On Sat, 21 Sep 2019 15:42:36, Ken Brown wrote: [snip] > I'll fix this and then look at your patches to mkdir and rmdir. It would > be very helpful if you would write these as a patch series with cover letter, > using git format-patch, and send them to the cygwin-patches list. Hi Ken, I think this will be my last post. In order to help you understand what I have been thinking, I describe (using terse language as in telegrams) what I think path_conv::check() in path.cc does (should do) with regard to "Unix path resolution", and as a _consequence_ of that understanding, what mkdir() and rmdir() in dir.cc must do. (also included are URLs to "standards" I have been studying) - 1. - Farewell I will be hospitalized soon, and I do not think I will be back here (any time soon?). Therefore, if you believe that the rational behind my modifications is valid, (and you like to do all this), you are welcome to carry them out yourself. I will not be able to carry them out myself. - 2. - rmdir(2) not in agreement w/ Posix (and Linux) 64-++ uname -a CYGWIN_NT-6.1 Seven 3.1.0(0.340/5/3) 2019-09-15 17:57 x86_64 Cygwin 64-++ ln -s bar foo 64-++ ls -l foo lrwxrwxrwx 1 Henri None 3 Sep 22 07:28 foo -> bar 64-++ mkdir bar 64-++ rmdir foo rmdir: failed to remove 'foo': Not a directory <==== Correct! 64-++ rmdir foo/ # directory bar has been deleted -- Posix does not # allow this to happen! 64-++ ls -l bar ls: cannot access 'bar': No such file or directory The same applies to mkdir(2). Eric Blake fixed mkdir() in winsup/cygwin/dir.cc in 2009, but he did not fix rmdir() in winsup/cygwin/dir.cc at the same time. Why he did not, I am unable to tell. - 3. - Path Resolution Call flow: mkdir() (and rmdir() ) in winsup/cygwin/dir.cc path_conv::check() in winsup/cygwin/path.cc <==== path resolution mkdir() (or rmdir(2) ) in winsup/cygwin/fhandler_disk_file.cc To simplify what happens when either mkdir(1) or rmdir(1) is called: - mkdir() (and rmdir() ) in dir.cc are "the system call entries" - path_conv::check() performs the "Unix path resolution" (and a lot of other things, I do not care about at the moment) - mkdir() (likewise rmdir() ) in fhandler_disk_file.cc is called by mkdir() in dir.cc, but only if the latter is "satisfied" with the result of path resolution - mkdir() (and rmdir() ) in fhandler_disk_file.cc do not perform path resolution -- these functions use the path as "computed" by path_conv::check() Path Resolution (summarized): pathname = /prefix/final[/] (in general, there is a difference between a path not ending w/ slash and a pathname that ends w/ a slash) - if final/ is a symlnk, it is followed and the target must exist and must be a directory - the exceptions to this rule are mkdir(2) and rmdir(2) (in principle, both these system calls ignore (strip!) the trailing slash) - if final is a symlnk, it is followed by default (but the target does not have to exist, let alone be a directory) - however a system call can specify that the symlnk must NOT be followed; mkdir(2) and rmdir(2) are examples of these system calls (because, again, both mkdir(2) and rmdir(2) do _not_ accept a symlnk as argument, according to specification) path_conv::check() is "common code" to all system calls w/ arguments that specify a pathname, i.e. this method does NOT know about the system calls mkdir() and rmdir(). This method only knows whether or not the pathname ended w/ a slash or not, and whether or not the system call specified to follow a symlnk or not (only relevant in case the pathname did NOT end w/ a slash). Because both mkdir(2) and rmdir(2) should not accept a symlnk as argument, they must both strip trailing slashes AND specify "do not follow". My understanding of what "path resolution" must do (that is, what method path_conv::check() must do wrt Unix path resolution, is based on studying the URLs I include below. Regards, Henri ----- file: references.txt Bzzt. Posix goes over the top in an attempt to make the difference between final and final/ as general as is possible. According to Posix (with regard to "path resolution"), both mkdir(newdir/) and rmdir(existing-dir/) obey the rules. [1] - However the argument to both mkdir(2) and rmdir(2) must be a directory; a symbolic link is NOT allowed in case of these system calls ("functions"). Said differently, there is NO need to specify the argument WITH a trailing slash: confusion does not exist: the argument must be a directory. Moreover, if a symbolic link is specified as an argument in these cases, "path resolution" should NOT follow this symbolic link. That is why both mkdir(2) and rmdir(2) will strip a trailing slash; they also specify "do not follow" for the same reason. [1] however, my interpretation is, that rmdir(existing-dir/) should succeed if the target of "existing-dir" (a symbolic link) s indeed a directory ... But that is wrong! (a symlnk as argument should be rejected by rmdir(2)! ) Similar reasoning applies to mkdir(newdir/) -- the call should be rejected if "newdir" is a symlnk. Linux ignores the difference between final and final/ in case of mkdir(2) and rmdir(2) - the trailing slash is irrelevant here - and silently strips the trailing slash (any implementation will do the same thing in order to be "posix-compliant"). References: Posix: The Open Group Base Specifications Issue 7, 2018 edition IEEE Std 1003.1-2017 (Revision of IEEE Std 1003.1-2008) Copyright (c) 2001-2018 IEEE and The Open Group - https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_13 ( 4.13 Pathname Resolution -- general concepts ) - https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap04.html#tag_21_04_13 ( A.4.13 Pathname Resolution -- appendix ) "POSIX.1-2017 requires that a pathname with a trailing <slash> be rejected unless it refers to a file that is a directory or to a file that is to be created as a directory." Henri: this would allow rmdir(existing-dir/), where existing-dir is a symlnk that refers to an _existing_ Henri: directory to succeed; but that is wrong! rmdir(2) does not allow a symlnk as an argument! Henri: similar reasoning applies to mkdir(newdir/) -- mkdir(2) must reject the call if newdir is a symlnk. - - https://pubs.opengroup.org/onlinepubs/9699919799/functions/mkdir.html ( mkdir(2) -- functions ) "If path names a symbolic link, mkdir() shall fail and set errno to [EEXIST]." - https://pubs.opengroup.org/onlinepubs/9699919799/functions/rmdir.html ( rmdir(2) -- functions ) "If path names a symbolic link, then rmdir() shall fail and set errno to [ENOTDIR]." Linux: - http://man7.org/linux/man-pages/man7/path_resolution.7.html ( man 7 path_resolution ) "Step 3: find the final entry -- Henri: (Linux!) the final entry is WITHOUT a trailing slash Henri: (Linux!) final/ is not considered the final entry: it must be a directory (or if a symlink, the target must be directory) and that directory must exist. The lookup of the final component of the pathname goes just like that of all other components, as described in the previous step, with two Henri: that is, a symlnk is followed BY DEFAULT! differences: (i) the final component need not be a directory (at least as far as the path resolution process is concernedâit may have to be a directory, or a nondirectory, because of the requirements of the specific system call), and (ii) it is not necessarily an error if the component is not foundâmaybe we are just creating it. The details on the treatment of the final entry are described in the manual pages of the specific system calls." Henri: in case of final (i.e. w/o trailing slash), a system call can direct Henri: "path resolution" NOT to follow a symlnk (my interpretation) "Final symlink Henri: (Linux!) again, the final symlink is WITHOUT a trailing slash! If the last component of a pathname is a symbolic link, then it depends on the system call whether the file referred to will be the symbolic link or the result of path resolution on its contents. For example, the system call lstat(2) will operate on the symlink, while stat(2) operates on the file pointed to by the symlink." ---------- Henri: my conclusion wrt "path resolution": - if final/ is a symlnk, it is followed and the target must exist and must be a directory - the exceptions to this rule are mkdir(2) and rmdir(2) (in principle, both these system calls ignore (strip!) the trailing slash) - if final is a symlnk, it is followed by default (but the target does not have to exist, let alone be a directory) - however a system call can specify that the symlnk must NOT be followed; mkdir(2) and rmdir(2) are examples of these system calls (because, again, both mkdir(2) and rmdir(2) do _not_ accept a symlnk as argument, according to specification) ---------- - http://man7.org/linux/man-pages/man7/symlink.7.html ( man 7 symlink ) "System calls The first area is symbolic links used as filename arguments for system calls. Except as noted below, all system calls follow symbolic links. For example, if there were a symbolic link slink which pointed to a file named afile, the system call open("slink" ...) would return a file descriptor referring to the file afile." - http://man7.org/linux/man-pages/man2/mkdir.2.html ( man 2 mkdir ) "EEXIST: pathname already exists (not necessarily as a directory). This includes the case where pathname is a symbolic link, dangling or not." - http://man7.org/linux/man-pages/man2/rmdir.2.html ( man 2 rmdir ) "ENOTDIR: pathname, or a component used as a directory in pathname, is NOT, in fact, a directory." - - https://lwn.net/Articles/649115/ ( Pathname lookup in Linux -- June, 2015, by Neil Brown ) - https://www.kernel.org/doc/html/latest/filesystems/path-lookup.html ( Pathname lookup ) ===== -- 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ... 2019-09-22 7:34 ` Houder @ 2019-09-22 14:12 ` Ken Brown 0 siblings, 0 replies; 32+ messages in thread From: Ken Brown @ 2019-09-22 14:12 UTC (permalink / raw) To: cygwin On 9/22/2019 3:11 AM, Houder wrote: > - 1. - Farewell > > I will be hospitalized soon, and I do not think I will be back here (any > time soon?). I'm very sorry to hear that. Thanks for your contributions. Best wishes, Ken -- 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ... 2019-08-28 15:18 ` Corinna Vinschen 2019-08-29 15:19 ` Houder @ 2019-09-07 3:47 ` L A Walsh 1 sibling, 0 replies; 32+ messages in thread From: L A Walsh @ 2019-09-07 3:47 UTC (permalink / raw) To: cygwin On 2019/08/28 07:22, Corinna Vinschen wrote: > One problem here is, what to do about border cases like > > $ mkdir a\/\/\/ > > In theory slashes and backslashes should both be treated as dir > separators. Handling a case like this so that all expectations > are satisfied is next to impossible, I guess. > In a shell or as a quoted literal? Under POSIX or under Windows? In a shell it ends up as: > pathcat a\/\/\/\/ b a/b > pathcat a\/\/ b a/b But as a quoted string, things don't get reduced unless last of first + first of second are same: > pathcat 'a\/\/' 'b' a\/\/b # cuddled > pathcat 'a\/\/' '/b' a\/\/b # slash reduced pathcat 'a\/\/' '\/b' a\/\/\/b # concat pathcat 'a\/\' '\/b' a\/\/\/b # slash added as "\/b is assumed to be at ./\/b Note that while posix may specify that mkdir 'a' and 'a/' should be the same, 'a:' and 'a:\' are not (and would not be POSIX compliant). -- 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ... 2019-08-27 16:28 ` Corinna Vinschen 2019-08-27 17:01 ` Houder @ 2019-08-27 19:48 ` Achim Gratz 2019-08-27 20:58 ` Brian Inglis 2019-08-27 22:21 ` Achim Gratz 1 sibling, 2 replies; 32+ messages in thread From: Achim Gratz @ 2019-08-27 19:48 UTC (permalink / raw) To: cygwin Corinna Vinschen writes: > 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). While we're discussing oddities, creating symbolic links in the virtual /dev directory still works and those links show up in the real (underlying) Windows directory as well. This is why the Bash postinstall still works and I'm not sure if it should do that the way it's written. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra -- 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ... 2019-08-27 19:48 ` Achim Gratz @ 2019-08-27 20:58 ` Brian Inglis 2019-08-28 7:16 ` Corinna Vinschen 2019-08-27 22:21 ` Achim Gratz 1 sibling, 1 reply; 32+ messages in thread From: Brian Inglis @ 2019-08-27 20:58 UTC (permalink / raw) To: cygwin On 2019-08-27 11:54, Achim Gratz wrote: > Corinna Vinschen writes: >> 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). > > While we're discussing oddities, creating symbolic links in the virtual > /dev directory still works and those links show up in the real > (underlying) Windows directory as well. This is why the Bash > postinstall still works and I'm not sure if it should do that the way > it's written. https://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-posixdevices lists the process devs, "udevs", and NT mappings, and specifies that the /dev directory is real to allow symlinks like cdrom/dvdrw -> sr0/scd0 and gps0/pps0/gpspps0 -> ttyS0. I notice /dev/kmsg documented but no longer appears, but /dev/log[=] exists if syslog-ng is running; and /dev/pipe and /dev/fifo are mentioned but don't exist. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. -- 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ... 2019-08-27 20:58 ` Brian Inglis @ 2019-08-28 7:16 ` Corinna Vinschen 0 siblings, 0 replies; 32+ messages in thread From: Corinna Vinschen @ 2019-08-28 7:16 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1209 bytes --] On Aug 27 14:37, Brian Inglis wrote: > On 2019-08-27 11:54, Achim Gratz wrote: > > Corinna Vinschen writes: > >> 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). > > > > While we're discussing oddities, creating symbolic links in the virtual > > /dev directory still works and those links show up in the real > > (underlying) Windows directory as well. This is why the Bash > > postinstall still works and I'm not sure if it should do that the way > > it's written. > > https://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-posixdevices > lists the process devs, "udevs", and NT mappings, and specifies that the /dev > directory is real to allow symlinks like cdrom/dvdrw -> sr0/scd0 and > gps0/pps0/gpspps0 -> ttyS0. > > I notice /dev/kmsg documented but no longer appears, but /dev/log[=] exists if > syslog-ng is running; and /dev/pipe and /dev/fifo are mentioned but don't exist. Some of this is old cruft. But hey, documentation fixes are just as welcome as code fixes ;) Corinna -- Corinna Vinschen Cygwin Maintainer [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ... 2019-08-27 19:48 ` Achim Gratz 2019-08-27 20:58 ` Brian Inglis @ 2019-08-27 22:21 ` Achim Gratz 1 sibling, 0 replies; 32+ messages in thread From: Achim Gratz @ 2019-08-27 22:21 UTC (permalink / raw) To: cygwin Achim Gratz writes: > Corinna Vinschen writes: >> 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). > > While we're discussing oddities, creating symbolic links in the virtual > /dev directory still works and those links show up in the real > (underlying) Windows directory as well. This is why the Bash > postinstall still works and I'm not sure if it should do that the way > it's written. Nevermind, I tried again on two machines (including the one I tested this on yesterday) and I can't reproduce it. :-P Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ... 2019-08-27 15:25 Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' Houder 2019-08-27 16:28 ` Corinna Vinschen @ 2019-08-28 13:36 ` Eric Blake 2019-08-28 22:57 ` Houder 1 sibling, 1 reply; 32+ messages in thread From: Eric Blake @ 2019-08-28 13:36 UTC (permalink / raw) To: cygwin [-- Attachment #1.1: Type: text/plain, Size: 1769 bytes --] 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. Patches welcome. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ... 2019-08-28 13:36 ` Eric Blake @ 2019-08-28 22:57 ` Houder 0 siblings, 0 replies; 32+ messages in thread From: Houder @ 2019-08-28 22:57 UTC (permalink / raw) To: cygwin; +Cc: eblake 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
end of thread, other threads:[~2019-09-22 11:55 UTC | newest] Thread overview: 32+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-08-27 15:25 Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' Houder 2019-08-27 16:28 ` Corinna Vinschen 2019-08-27 17:01 ` Houder 2019-08-27 17:32 ` Vince Rice 2019-08-27 17:50 ` Corinna Vinschen 2019-08-28 7:16 ` Houder 2019-08-28 9:22 ` john doe 2019-08-28 11:47 ` Houder 2019-08-28 13:22 ` Corinna Vinschen 2019-08-28 14:16 ` Eric Blake 2019-08-28 14:22 ` Corinna Vinschen 2019-08-28 15:18 ` Corinna Vinschen 2019-08-29 15:19 ` Houder 2019-08-30 8:20 ` Corinna Vinschen 2019-08-30 12:42 ` Houder 2019-09-01 17:38 ` Houder 2019-09-02 8:15 ` Corinna Vinschen 2019-09-03 8:40 ` Houder 2019-09-03 6:50 ` Andrey Repin 2019-09-19 19:51 ` Ken Brown 2019-09-20 9:11 ` Houder 2019-09-20 18:20 ` Houder 2019-09-21 16:07 ` Ken Brown 2019-09-22 7:34 ` Houder 2019-09-22 14:12 ` Ken Brown 2019-09-07 3:47 ` L A Walsh 2019-08-27 19:48 ` Achim Gratz 2019-08-27 20:58 ` Brian Inglis 2019-08-28 7:16 ` Corinna Vinschen 2019-08-27 22:21 ` Achim Gratz 2019-08-28 13:36 ` Eric Blake 2019-08-28 22:57 ` Houder
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).