Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ...

Eric Blake eblake@redhat.com
Wed Aug 28 13:36:00 GMT 2019

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://cygwin.com/pipermail/cygwin/attachments/20190828/f3130e94/attachment.sig>

More information about the Cygwin mailing list