From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22310 invoked by alias); 20 Sep 2019 07:56:04 -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 22301 invoked by uid 89); 20 Sep 2019 07:56:04 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.1 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_2,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.1 spammy=H*M:smtp, H*F:D*nl, ic, HX-Languages-Length:2024 X-HELO: lb1-smtp-cloud7.xs4all.net Received: from lb1-smtp-cloud7.xs4all.net (HELO lb1-smtp-cloud7.xs4all.net) (194.109.24.24) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 20 Sep 2019 07:56:01 +0000 Received: from tmp.hjHfGJLMsA ([83.162.234.136]) by smtp-cloud7.xs4all.net with ESMTPSA id BDlliTyjX9D4hBDlmicZSW; Fri, 20 Sep 2019 09:55:59 +0200 Date: Fri, 20 Sep 2019 09:11:00 -0000 Message-ID: From: Houder Reply-To: cygwin@cygwin.com To: cygwin@cygwin.com Subject: Re: Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ... References: <20190827152549.GY11632@calimero.vinschen.de> <3E262D05-F393-453A-9E43-B248DDE50812@solidrocksystems.com> <20190828125939.GL11632@calimero.vinschen.de> <421ac447-b249-da21-1ca5-228041cfc884@redhat.com> <20190828141556.GM11632@calimero.vinschen.de> <20190828142220.GN11632@calimero.vinschen.de> <4a87b7a940fb0cf76aac5f3bc5b1a8b3@smtp-cloud7.xs4all.net> In-Reply-to: Content-Type: text/plain; charset=UTF-8; format=fixed User-Agent: mua.awk 0.99 X-SW-Source: 2019-09/txt/msg00211.txt.bz2 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