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:cc:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=P6iC8j01JSmJFejiNp8AmrSeKnMNscQL84LmclPA0Wo9Fnyg9MfjG
	OhgxPtADMiOVj/3rkY2XHc/FgjNX6nX3mcNAN//uBUaSIzb3pwkRSVSJNnB2zzSZ
	RMS4NcMqUMCRFty4j61s8Z19yP3PGzhj1Iy237ulKvuDg9bmX05Jbg=
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:cc:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; s=default;
	 bh=TdqNlFHiwXlinnJLEpBzRho+fro=; b=O95pesrMfKIBkVlb1JiDm9oQiIhn
	8GIYQpKLHisreACwNEifgIskhHTgag+rILRacZ8f4HuykCcbMrI65EuiiCUdU1Rf
	oUjqbtnYi9a0KIUURtNl+MT8W024UtgNj8XPiZLDTu/1rh6rQsCIDlqwSkWjKlPa
	QmDWivIB6iC4TVU=
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=Yeah, thx, solely
X-HELO: calimero.vinschen.de
Date: Thu, 4 Aug 2016 11:13:14 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Cc: Franz Sirl <Franz DOT Sirl-kernel AT lauterbach DOT com>
Subject: Re: Size limitation for NcFsd drive?
Message-ID: <20160804091314.GB2333@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com,	Franz Sirl <Franz DOT Sirl-kernel AT lauterbach 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> <20160802145926 DOT GM3470 AT calimero DOT vinschen DOT de>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;	protocol="application/pgp-signature"; boundary="pQhZXvAqiZgbeUkD"
Content-Disposition: inline
In-Reply-To: <20160802145926.GM3470@calimero.vinschen.de>
User-Agent: Mutt/1.6.2 (2016-07-01)

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

Franz?  Ping?


Thx,
Corinna

On Aug  2 16:59, Corinna Vinschen wrote:
> Hi Franz,
>=20
> 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 seco=
nd
> > > > 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 ca=
ll
> > >   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 dri=
ves
> > and SMB shares the STATUS_BUFFER_OVERFLOW turns into STATUS_SUCCESS as =
soon
> > 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?).
>=20
> 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.
>=20
> 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.
>=20
> > But for the NCP share the strange error code for
> > FileAllInformation remains. Checking all the members of FileAllInformat=
ion
> > one by one, it turned out that it's the FileInternalIformation member t=
hat
> > fails. I've reported it as a bug to Novell.
>=20
> 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=
.85).aspx
>=20
> However, do we need a workaround?  Kind of like this:
>=20
> 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 thr=
ead
> +     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=20
>=20
> > Nevertheless I believe the fallback to
> > NtQueryDirectoryFile(FileIdBothDirectoryInformation) does not do what y=
ou
> > want if the path is the root directory of a share. But that's not the c=
ause
> > of this problem.
>=20
> 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.
>=20
> Are you set up to build your own Cygwin DLL so you can test the above
> patch locally?
>=20
>=20
> Thanks,
> Corinna
>=20
> --=20
> Corinna Vinschen                  Please, send mails regarding Cygwin to
> Cygwin Maintainer                 cygwin AT cygwin DOT com
> Red Hat



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

--pQhZXvAqiZgbeUkD
Content-Type: application/pgp-signature; name="signature.asc"

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

iQIcBAEBCAAGBQJXowcqAAoJEPU2Bp2uRE+g0mwP/2YB16G/W4RKXKY0bbVC3PFd
haPr76Up7KtYaowTluc7fDTAtMVdOpzATvkvPDIRJWmC8+dd+Lm0At4E72mlsZZH
W02p2T2CSz+vqQF97RhhypVPmvXmp2W702MY0wyxbuB0cYF+Gy4B+EtHM2kL1qNl
DynZMQIV6C884TeYvS3SYGAE9kbHU3TZmGlYQt4k06KLZxr15DhyXPJrEo0CxeFR
6Pm3nX22sDdbGQPoTSKKMI+aoxfBN8eQ3uNFYbsfzHfMIjhWt/zKOxEeOPNGu8Xc
AI5hkgoiDaTFWNG5uS0vwnNTTGblYn8pubsj5iocZlrykVOKoUYCazKN53jQb+U9
O8jqDcGtXFSr1gbhxCccXncHBeWsy/iOv3i/9POFVil3IzV+6yavNnB3B1MX2jJt
qNiEQj0FjaG6byoz0PLb6ns6G73lGobSRViYfu/6TQWIG9juyE8PTRaVu/B7zxVC
0s+1YT2/SAnJDydN2AgcyG2ZoTAC3tpwrdRpfrKQX53OBRMZw9I+akayatlh8532
Q82ZR52YFJ30laKy+QcYVT6sdNiUjWEXPCMkRdGX9bzoOYx4jLowMbKKzed8JfVy
uhXnujjwBLXXeH1MNToTIgrlo5NLAv+X93Pa8D8H18apwHp/KTmcBfU9Rzjikoi5
HJJiN9CazK/7N4lfGqu8
=W1AI
-----END PGP SIGNATURE-----

--pQhZXvAqiZgbeUkD--