This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ...
- From: Houder <houder at xs4all dot nl>
- To: cygwin at cygwin dot com
- Cc: eblake at redhat dot com
- Date: Sun, 01 Sep 2019 19:38:11 +0200
- Subject: Re: Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ...
- References: <bc3df101ab93c20b86c3ab7fa7d3ea4f@xs4all.nl> <20190827152549.GY11632@calimero.vinschen.de> <a47cc167b725c08e6f1c914166fabcaf@smtp-cloud8.xs4all.net> <3E262D05-F393-453A-9E43-B248DDE50812@solidrocksystems.com> <b97e4dbe952154efc68412540514ae81@smtp-cloud8.xs4all.net> <20190828125939.GL11632@calimero.vinschen.de> <421ac447-b249-da21-1ca5-228041cfc884@redhat.com> <20190828141556.GM11632@calimero.vinschen.de> <20190828142220.GN11632@calimero.vinschen.de> <ee1138b29ee4be60d62d86d59f581b2e@smtp-cloud8.xs4all.net> <4a87b7a940fb0cf76aac5f3bc5b1a8b3@smtp-cloud7.xs4all.net>
- Reply-to: cygwin at cygwin dot com
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