This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 3.0.7(0.338/5/3): Possible reference to Developer's instances of dev files in deployed build


>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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]