X-Recipient: archive-cygwin AT delorie DOT com
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:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=mgIhr659dP2ehkiaVpgCmL2KZOQsqqrE90+hlR54hCcY0fvyJfzA5
	DMOtLwoZkAfCslcYvpxDzh7kRm1rOFASO2IVZl2BsPC/PKiF0RxVlr99EIuiWrIt
	X7yKmZ//TwmV+84Xm4uqpPx8Zls+Qqe4LhjIDpCLb9htu6OflrqPWU=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; s=default;
	 bh=wK39DJZWIjEj1BGYecGQe+M0+CA=; b=F5kBPU76AvliTphcWl0W1SU2Tzz9
	Dui62wlpg5VBAjISWg1+71fzdBPSJIWNUM2GBpgcIp82FOywtJYra/Z5ybPcx2Ea
	z0PkzDStkSfClDnxAFY7RTqNNFTxCxeqE/KJ3L1EJigDjkRy6haf2FKpG5AWYWvX
	B/EYnwgpTzZZWjg=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-95.0 required=5.0 tests=AWL,BAYES_00,GOOD_FROM_CORINNA_CYGWIN,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_BRBL_LASTEXT,RCVD_IN_PBL,RCVD_IN_SORBS_DUL,RDNS_DYNAMIC autolearn=ham version=3.3.2 spammy=aspx, sirl, Sirl, Franz
X-HELO: calimero.vinschen.de
Date: Tue, 2 Aug 2016 16:59:26 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Size limitation for NcFsd drive?
Message-ID: <20160802145926.GM3470@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <2483665a-eae1-737d-59f2-ca6af9428aca AT lauterbach DOT com> <2b6c3324-0a18-7437-c85b-bb30d3cbdbae AT lauterbach DOT com> <20160728195859 DOT GE26311 AT calimero DOT vinschen DOT de> <8ffdb11a-a2a6-109b-988d-2d5f38c98731 AT lauterbach DOT com> <20160729141831 DOT GA9364 AT calimero DOT vinschen DOT de> <20160729143815 DOT GE5963 AT calimero DOT vinschen DOT de> <dc4405e7-94c8-b24d-71ea-2359578fc30b AT lauterbach DOT com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;	protocol="application/pgp-signature"; boundary="Ublo+h3cBgJ33ahC"
Content-Disposition: inline
In-Reply-To: <dc4405e7-94c8-b24d-71ea-2359578fc30b@lauterbach.com>
User-Agent: Mutt/1.6.2 (2016-07-01)

--Ublo+h3cBgJ33ahC
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi Franz,

On Aug  2 16:26, Franz Sirl wrote:
> Am 2016-07-29 um 16:38 schrieb Corinna Vinschen:
> > On Jul 29 16:18, Corinna Vinschen wrote:
> > > In the first place it would be prudent to find out why the
> > > FileAllInformation info class fails on this drive.  And in the second
> > > place it would be important to find out how to fix this.  Potential
> > > checks:
> > >=20
> > > - Buffer alignment of the FILE_ALL_INFORMATION member in class
> > >   path_conv_handle.
> > >=20
> > > - Buffer size of the FILE_ALL_INFORMATION member.  For instance,
> > >   does it work if the buffer is 1 byte bigger?  Or perhaps if
> > >   the buffer is NAME_MAX bigger?
> >=20
> > - There's also a chance (albeit minor) that the FileAllInformation call
> >   actually worked and the weird status code is just wrong.  After all,
> >   returning from this call with STATUS_BUFFER_OVERFLOW is valid, too,
> >   so I'd check for this as well here.
>=20
> Hi Corinna,
>=20
> no, the error code isn't influenced by alignment or size. For local drives
> and SMB shares the STATUS_BUFFER_OVERFLOW turns into STATUS_SUCCESS as so=
on
> as there is enough room for the share path in the
> FILE_NAME_INFORMATION.FileName flexible array member (actually, why isn't
> path_conv_handle.attribs._fai larger? performance? FileNameInformation
> usually not needed?).

FileNameInformation is the full path to the file.  It's not only not
needed, but for full long pathname support the buffer would have to
be sizeof (FILE_ALL_INFORMATION) + 32767 * sizeof (WCHAR), thus more
than 64K in size.

FileAllInformation is designed so that you can ask for all information
except the filename by just ignoring the name buffer requirements.  In
that case NtQueryInformationFile returns STATUS_BUFFER_OVERFLOW, which
can be ignored.

> But for the NCP share the strange error code for
> FileAllInformation remains. Checking all the members of FileAllInformation
> one by one, it turned out that it's the FileInternalIformation member that
> fails. I've reported it as a bug to Novell.

Cool.  NtQueryInformationFile is supposed to just set all unsupported
members to 0, see the Remarks section of
https://msdn.microsoft.com/en-us/library/windows/hardware/ff567052(v=3Dvs.8=
5).aspx

However, do we need a workaround?  Kind of like this:

diff --git a/winsup/cygwin/path.cc b/winsup/cygwin/path.cc
index 970a0fe..d9ed357 100644
--- a/winsup/cygwin/path.cc
+++ b/winsup/cygwin/path.cc
@@ -1307,6 +1307,19 @@ file_get_fai (HANDLE h, PFILE_ALL_INFORMATION pfai)
 				   FileAllInformation);
   if (status =3D=3D STATUS_BUFFER_OVERFLOW)
     status =3D STATUS_SUCCESS;
+  /* Filesystems with broken FileAllInformation exist, too.  See the thread
+     starting with https://cygwin.com/ml/cygwin/2016-07/msg00350.html. */
+  else if (!NT_SUCCESS (status) && status !=3D STATUS_ACCESS_DENIED)
+    {
+      memset (pfai, 0, sizeof *pfai);
+      status =3D NtQueryInformationFile (h, &io, &pfai->BasicInformation,
+				       sizeof pfai->BasicInformation,
+				       FileBasicInformation);
+      if (NT_SUCCESS (status))
+	status =3D NtQueryInformationFile (h, &io, &pfai->StandardInformation,
+					 sizeof pfai->StandardInformation,
+					 FileStandardInformation);
+    }
   return status;
 }
=20

> Nevertheless I believe the fallback to
> NtQueryDirectoryFile(FileIdBothDirectoryInformation) does not do what you
> want if the path is the root directory of a share. But that's not the cau=
se
> of this problem.

Yeah, as I wrote in my reply, the NtQueryDirectoryFile branch isn't
supposed to be hit in this scenario.  It's solely for "access denied"
situations.

Are you set up to build your own Cygwin DLL so you can test the above
patch locally?


Thanks,
Corinna

--=20
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--Ublo+h3cBgJ33ahC
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJXoLVOAAoJEPU2Bp2uRE+glK0P/A532Pkc7QFykpSMJlyaMmL/
6YGBGDqN20PU0xl9n/Gw1pYM+yTgtqOz/1HVILX0yN62k5s2doVifeuIoLydiDKE
bFgmmvwu4a8tdHj0Vscw9Jcb2N++6gWV1A/oA/5XLN3u4qVvXjqzxR8IBTJTiHGE
Mwl9k7NllcBtPkx1plevLaPeR/FBsBI9R8WrmNlXWKJIbaC3Wo4xLM/iifa2EAVo
Q2oqu3+/I5omt/H8pgGpr43JiVDFxq8VIXkDaaw200VyrtC6g41KBeDpBm7pvhXE
oJLTdPB6Cj01RIru3CryQEOTfP6kGDSqQsC9N5HfN7K2lwP6LhQhHA4tnb3KcAkQ
Cv7z790uangGQ3WBI1WbZq8DH98MzFMmBb+vhdNQYrF0op7dI3NDAipdUme1hkVw
IFDr72QFHfdSx6HuZrU7p8Qx565p0JtfHiQla8bRCRMy6t77KNwF6YoYOH7b9FZa
cP0zcHdhZ+eITD8Q2gskLpQIztiSopPzdfVVUJYmmJRif647hAeoMkuEabNDUe6d
9Nl2OxvMIr8lsCPBd4CS0vPUuHI3c5ml/EVOnHecrAb6U2AjxWa87LWyDOzn1P4U
TpvSDxnDLOEuJELsVirJgXfchefcyMbEScImE4iM4De6PNxrjmsD0wAqbh+RsiOY
MVC2e7boxomTkO3H7IHq
=a9Gw
-----END PGP SIGNATURE-----

--Ublo+h3cBgJ33ahC--