From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 111932 invoked by alias); 6 Dec 2019 04:56:23 -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 111920 invoked by uid 89); 6 Dec 2019 04:56:23 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=BAYES_00,FAKE_REPLY_C,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=exhibited, professional, online, emails X-HELO: re-prd-fep-040.btinternet.com Received: from mailomta10-re.btinternet.com (HELO re-prd-fep-040.btinternet.com) (213.120.69.103) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 06 Dec 2019 04:56:21 +0000 Received: from re-prd-rgout-003.btmx-prd.synchronoss.net ([10.2.54.6]) by re-prd-fep-040.btinternet.com with ESMTP id <20191206045618.UEPB11338.re-prd-fep-040.btinternet.com@re-prd-rgout-003.btmx-prd.synchronoss.net> for ; Fri, 6 Dec 2019 04:56:18 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btinternet.com; s=btmx201904; t=1575608178; bh=+cIOfD+o6QgA/V9rJbJwlt6zv5WgqR6dgLQRfz1erQw=; h=Date:From:To:Subject:Message-ID:Reply-To:MIME-Version; b=Hd4W6FiPOEw0RWzIBlA+a8laE7Og5U+eYkK0zjQK/t8QHA0JMA7OaKCMznQhLHRcI2KPL+UkIR+e3SNjpp1/BHE5Di5b7Mh12hiLXzVwZF2gKpU9E4RIstZYmdC8l6Ziixn4cSK3afEMqmYnkhY/Qna1P0QbKJHQ0SlAvV7+aqkpCZ/NUpdHanWPLfNv6e8RzWkkACsDjEfvjLWMrWj3P9PTxOGLoZxfvDAOMpk7lDkGC4/q5pFBBoRoVTlJIdifR8C3QTr5ucUse0u7UIVOlDk6F2ieNQH+wJFTXrTxXqAQ8tFJyCfAUajridDFe6bGYkyXTGZ6x/txq6L3CZeN6g== Authentication-Results: btinternet.com; auth=pass (LOGIN) smtp.auth=olaf.sulla@btinternet.com X-OWM-Source-IP: 81.156.228.139 (GB) X-OWM-Env-Sender: olaf.sulla@btinternet.com X-VadeSecure-score: verdict=clean score=0/300, class=clean Received: from shackleton.labs.net (81.156.228.139) by re-prd-rgout-003.btmx-prd.synchronoss.net (5.8.337) (authenticated as olaf.sulla@btinternet.com) id 5DB305E2077C2772 for cygwin@cygwin.com; Fri, 6 Dec 2019 04:56:18 +0000 Date: Fri, 06 Dec 2019 04:56:00 -0000 From: "Wilfed Olaf Sulla via cygwin" Reply-To: Wilfed Olaf Sulla To: Cygwin Subject: Re: 3.0.7(0.338/5/3): Possible reference to Developer's instances of dev files in deployed build Message-ID: <20191206045537.GA22631@shackleton.labs.net> Reply-To: Wilfed Olaf Sulla MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.12.1 (2019-06-15) X-SW-Source: 2019-12/txt/msg00037.txt.bz2 >On 12/5/2019 2:16 PM, Corinna Vinschen wrote: >> On Dec 5 16:10, Ken Brown wrote: >>> On 12/5/2019 7:52 AM, Corinna Vinschen wrote: >>>> On Dec 5 10:18, Corinna Vinschen wrote: >>>>> On Dec 4 21:41, Ken Brown wrote: >>>>>> The difference is that NtCreateFile doesn't fail with >>>>>> STATUS_OBJECT_NAME_NOT_FOUND in the other cases, so the code containing the >>>>>> assertion doesn't get run. >>>>>> >>>>>> BTW, I just tried the following on my system: >>>>>> >>>>>> $ ls z:\\ >>>>>> ls: cannot access 'z:\': No such file or directory >>>>>> >>>>>> strace shows that NtCreateFile fails with STATUS_OBJECT_PATH_NOT_FOUND in this >>>>>> case, so again the code containing the assertion is not run. >>>>>> >>>>>> To be continued... >>>>> >>>>> So, maybe we could just check if ext_here - path > 2, i. e. >>>>> >>>>> if (status == STATUS_OBJECT_NAME_NOT_FOUND && ext_here - path > 2) >>>>> >>>>> That excludes "X:" paths from this special handling for DOS-only drives. >>>> >>>> The only problem here is that I can't reproduce the assertion failure. >>>> >>>> I created a Samba share on a Linux machine, mounted it as drive Z:, >>>> and set the "always available offline" property of the drive. >>>> >>>> After syncing I accessed the drive, then I stopped Samba on the Linux >>>> server to switch the drive into offline mode. Then I ran `ls -la >>>> /cygdrive/z'. After a few secs I got the offline content cached on the >>>> local machine. I also tried `ls -la /cygdrive/' and `cd /cygdrive; ls >>>> -la', but every time I got the expected output. In the cases I tried >>>> to list /cygdrive itself I got the expected output, all drives except >>>> the z drive. >>>> >>>> I tried this with Cygwin 3.1.0-0.8.x86_64 on Windows 7 and Windows 10. >>>> >>>> So either there's something very special in Wilfed's setup, or I'm >>>> doing something wrong. Which is it? >>> >>> How does your strace output compare to Wilfed's when you list /cygdrive? Does >>> it show a failed attempt to list Z: with an error from NtCreateFile? >> >> Not at all. The strace doesn't show any attempt to open Z:. > >Then I wonder what's different about Wilfed's setup that causes an attempt to >open Z: when it's offline. > >I'm grasping at straws, but could the difference be related to the fact that his >drive Z: is not a Samba share? Here's an excerpt from the mount output in one >of his earlier emails (when Z: is online): > >V: on /cygdrive/v type smbfs (binary,noacl,posix=0,user,noumount,auto) >W: on /cygdrive/w type smbfs (binary,noacl,posix=0,user,noumount,auto) >X: on /cygdrive/x type smbfs (binary,noacl,posix=0,user,noumount,auto) >Y: on /cygdrive/y type smbfs (binary,noacl,posix=0,user,noumount,auto) >Z: on /cygdrive/z type cifs (binary,noacl,posix=0,user,noumount,auto) > ^^^^ > >Ken > Hi, The drive mapping was created in a Windows context for use within a Windows context - i.e. via Explorer - onto a device on a remote node; there has been no specific configuration applied within the context of Cygwin. Whether or not the device is available, there is a Z: drive mapping maintained within Explorer, however the /cygdrive/z/ mount is only available if the device is available. Thus I am guessing that the list of devices to be checked and transformed is taken from the information made available from the Windows context rather than with consideration of the Cygwin context, and thus the Z: drive is passed through the check and transform even though it is not listed by 'mount'. The problem is exhibited on: Windows 7 Professional Ver 6.1 Build 7601 Service Pack 1 ... with both the: Current Build: CYGWIN_NT-6.1 shackleton 3.1.0(0.340/5/3) 2019-11-19 13:58 x86_64 Cygwin ... and the build under which the problem was first observed: CYGWIN_NT-6.1 shackleton 3.0.7(0.338/5/3) 2019-04-30 18:08 x86_64 Cygwin The problem was exhibited following these two commands: shackleton:sulla:$ cd /cygdrive/ shackleton:sulla:$ ls -la Many thanks. -- Mutt 1.12.1 (2019-06-15) -- 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