X-Recipient: archive-cygwin AT delorie DOT com
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:message-id:from:reply-to:to:cc:subject
	:references:in-reply-to:content-type; q=dns; s=default; b=G3ZlXm
	tvr8kAAdZUCbK6lZjs9w2aIhwtRG/D0RB1u3GmtMs+sx49+3gPRtwyYOBp1Z3fAy
	vGkRxSEjNqXq2fQR1Mm049VAnbuundP7/dHRLo+JKAA6ob8PvCloEj0iclMh3nGk
	cHSGvdLQHS2RMkbh5ch8DsBeC/VFbjFf3/hkE=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:message-id:from:reply-to:to:cc:subject
	:references:in-reply-to:content-type; s=default; bh=odinF8IqfRXY
	27jhfa/OIk4IPCg=; b=DdbxhNpbiAhKR/ctbdQwTOh8EWghk6Ea+cSh+rICIMCa
	rg2stfbBlvcMnK7oAyDILxmC2liO3CkX5YuyBNC2NzEgwwA7nCxswn75Uc9qsH4X
	mIws+pQwNsZiBQxNHeTAIawJbIbc7viTieLkDMYaWBQhu5ul3Y/SkYdg/2mpAUU=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=-4.3 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_2,KAM_STOCKGEN,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.1 spammy=stopped, rough, reattach, consistent
X-HELO: lb2-smtp-cloud9.xs4all.net
Date: Sun, 01 Sep 2019 19:38:11 +0200
Message-ID: <e438666b60ee08a2a3ee4ca16015382f@smtp-cloud9.xs4all.net>
From: Houder <houder AT xs4all DOT nl>
Reply-To: cygwin AT cygwin DOT com
To: cygwin AT cygwin DOT com
Cc: eblake AT redhat DOT com
Subject: Re: Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ...
References: <bc3df101ab93c20b86c3ab7fa7d3ea4f AT xs4all DOT nl> <20190827152549 DOT GY11632 AT calimero DOT vinschen DOT de> <a47cc167b725c08e6f1c914166fabcaf AT smtp-cloud8 DOT xs4all DOT net> <3E262D05-F393-453A-9E43-B248DDE50812 AT solidrocksystems DOT com> <b97e4dbe952154efc68412540514ae81 AT smtp-cloud8 DOT xs4all DOT net> <20190828125939 DOT GL11632 AT calimero DOT vinschen DOT de> <421ac447-b249-da21-1ca5-228041cfc884 AT redhat DOT com> <20190828141556 DOT GM11632 AT calimero DOT vinschen DOT de> <20190828142220 DOT GN11632 AT calimero DOT vinschen DOT de> <ee1138b29ee4be60d62d86d59f581b2e AT smtp-cloud8 DOT xs4all DOT net> <4a87b7a940fb0cf76aac5f3bc5b1a8b3 AT smtp-cloud7 DOT xs4all DOT net>
In-Reply-to: <4a87b7a940fb0cf76aac5f3bc5b1a8b3@smtp-cloud7.xs4all.net>
Content-Type: text/plain; charset=UTF-8; format=fixed
User-Agent: mua.awk 0.99

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