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:from:reply-to:to:subject:message-id
	:reply-to:mime-version:content-type; q=dns; s=default; b=BYQN3Vo
	fVRnfI7evlOCKemEDLmvBMFJVVM5VuZ+EAynT2AGrbo9H8+6N4OCMcT/2owhscMQ
	WxQ5unXBMHrwPRw/qATq9aYAvbZZ8FnJIuJe2HoM/2c6I9bCJP+FiT3Xq64hQVoo
	aSa+G8zNYK7Y01rXBKfwbpWvigaU348uVBK8=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Date: Fri, 6 Dec 2019 04:55:37 +0000
From: "Wilfed Olaf Sulla via cygwin" <cygwin AT cygwin DOT com>
Reply-To: Wilfed Olaf Sulla <olaf DOT sulla AT btinternet DOT com>
To: Cygwin <cygwin AT cygwin DOT com>
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 <olaf DOT sulla AT btinternet DOT com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.12.1 (2019-06-15)

>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