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

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

On Dec  6 04:55, Wilfed Olaf Sulla via cygwin wrote:
> >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:
> >>>> 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.

That's not the point, actually.  Setting up drives is always a Windows
thingy.  Cygwin just reads the configuration and tries to map it into
a POSIX context.

> 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.

Right.  Cygwin uses a simple mechanism to check the drives to show
under /cygdrive.  Basically it just calls the Win32 function
GetLogicalDriveStrings(), then, for each drive, it checks the
QueryDosDevice mapping.  Right now it only accepts cdrom, floppy,
harddrive, LanmanRedirector (SMB) and MRxNfs (NFS).  All other
drive types are treated as "no disk".  This is fixable with probably not
too much effort.

> The problem is exhibited on:
> 
> Windows 7 Professional Ver 6.1 Build 7601 Service Pack 1

Yeah, that's what I tried, too, as I wrote, besides W10.  I'm still not
seeing the assertion failure.  I tried this with a "normal" mapping of
the remote drive, as well as with a drive marked "available offline", to
no avail.  That's why *maybe* the drive type is part of the problem.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

Attachment: signature.asc
Description: PGP signature