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=PxJsuIa7Dhop9uJQgoq2UY128IPjjZM/TovazttUpCMs5hAzg3LCL
	XRV3wXHAFZAr46o4pr1gBjiJedMIIUCeqR/JOraWEyDiO0z3LaaCG9T0JPOo0Rhg
	6zCgOhvf30qZBalbZrwDbiq306oFJgfllIgsJEYeLL4G62xXhVP/lI=
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=4wfXtPx3u61pW1Dkg96XQ56jBoc=; b=VmQV3HL6FgNIea/NK+S3cFS2Q8wf
	3JSXQM2KvE4cSF2Zv8VJf12CLlvuD7zBkwwL41lx4r0ZIPTdCts7g3OKaZKUb7dy
	l0nCyR8qPbvwTTjvmgJu5KGe+fmb75haNMGz1cJhZ9TkAwpY1ERae68fJt2KpMgs
	9omY4wnYHNXgJHw=
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=H*f:sk:8ffdb11, H*i:sk:8ffdb11, H*MI:sk:8ffdb11, 2800
X-HELO:	calimero.vinschen.de
Date:	Fri, 29 Jul 2016 16:18:31 +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:	<20160729141831.GA9364@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>
MIME-Version:	1.0
In-Reply-To:	<8ffdb11a-a2a6-109b-988d-2d5f38c98731@lauterbach.com>
User-Agent:	Mutt/1.6.2 (2016-07-01)

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

Hi Franz,

On Jul 29 15:25, Franz Sirl wrote:
> Am 2016-07-28 um 21:58 schrieb Corinna Vinschen:
> > Could it be permissions?  Can you send the output of `icacls T:'?
> >=20
> > Other than that, an strace of `ls -ld /cygdrive/t/.' might give a clue.
>=20
> Hi Corinna,
>=20
> no, it's not permissions, it's the order in which files are returned for
> directory enumeration. There is this code snippet around line ~2800 in
> path.cc:
>=20
>                   RtlSplitUnicodePath (&upath, &dirname, &basename);
> ....
>                   status =3D NtQueryDirectoryFile (dir, NULL, NULL, NULL,=
 &io,
> &fdi_buf, sizeof fdi_buf,
> FileIdBothDirectoryInformation,
>                                                  TRUE, &basename, TRUE);
>                   /* Take the opportunity to check file system while we're
>                      having the handle to the parent dir. */
>                   fs.update (&upath, dir);
>                   NtClose (dir);
>=20
> It tries to query the first entry returned and assumes (no idea if Windows
> guarantees that, POSIX does not AFAIK) that it is "."

No, not at all.  It was timply never intended that symlink_info::check's
NtQueryDirectoryFile branch is called for top-level dirs.  The path split
works under the assumption that we're in some subdir.

> this drive it is just some file that happens to be first in the directory
> enumeration. And then everything goes wrong from there.

Your below strace indicates it's going pear-shaped a bit earlier:

> The related strace excerpt shows:
>=20
>  1788  764507 [main] ls 7456 lstat64: entering
>    45  764552 [main] ls 7456 normalize_posix_path: src /cygdrive/t/.
>    44  764596 [main] ls 7456 normalize_posix_path: /cygdrive/t/ =3D
> normalize_posix_path (/cygdrive/t/.)
>    42  764638 [main] ls 7456 mount_info::conv_to_win32_path:
> conv_to_win32_path (/cygdrive/t)
>    49  764687 [main] ls 7456 mount_info::cygdrive_win32_path: src
> '/cygdrive/t', dst 'T:\'
>    46  764733 [main] ls 7456 set_flags: flags: binary (0x2)
>    44  764777 [main] ls 7456 mount_info::conv_to_win32_path: src_path
> /cygdrive/t, dst T:\, flags 0x4022, rc 0
>   372  765149 [main] ls 7456 symlink_info::check: 0x0 =3D NtCreateFile
> (\??\T:\)

that's the debug_printf on line 2674.  NtCreateFile succeeds.

>   316  765465 [main] ls 7456 symlink_info::check: 0xC7E90006 =3D
> NtQueryInformationFile (\??\T:\)

This is the debug_printf on line 2766.  The status code returned at
this point is from conv_hdl.get_finfo() which in turn calls
file_get_fai(), defined in path.cc at line 1299ff.

I never saw this status code 0xC7E90006 before, but it comes very
likely from the device driver itself.  What that means is that
NtQueryInformationFile (..., FileAllInformation) has gone awry for
some reason.

This is a bit of a bummer.  FileAllInformation should work on all
supported filesystems.

> So upath was likely "\??\T:\" and I guess RtlSplitUnicodePath() returned
> "" or "*.*" for basename.

Don't guess, debug it!  Either install the cygwin-debuginfo package,
or build your own Cygwin without optimization for easier debugging.

> Maybe a possible fix/workaround would be to force basename to "." in this
> case?

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:

- Buffer alignment of the FILE_ALL_INFORMATION member in class
  path_conv_handle.

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

- If the above fails, adding a code path to file_get_fai for broken
  filesystems which calls NtQueryInformationFile twice, once with
  FileBasicInformation, once with FileStandardInformation info class.

  The old version of the function, called file_get_fnoi, had some
  code along these lines already.  For reference see

    git show eed35efb

> And, as an explanation, this happened because during the copying of this
> share
> the filesystem was changed from pure ext3 to ext3 with dir_index enabled.
> With
> dir_index enabled the directory entries are enumerated in an order dictat=
ed
> by the hashing I guess. I turned of the dir_index feature and Cygwin star=
ted
> working normally again on this drive. But note that it only works because
> now "a directory" is returned as first entry, but it seems it's usually n=
ot
> "." with NcFsd. Seems like it worked by accident before.

Yes, that may be the case.  We might have to revert code along the
lines of the old file_get_fnoi function to make it work again.
The desired result is that we *don't* call the NtQueryDirectoryFile
code path.  This is meant to be used only for files and dirs with no
permission to read their meta data.


HTH,
Corinna

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

--+QahgC5+KEYLbs62
Content-Type: application/pgp-signature; name="signature.asc"

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

iQIcBAEBCAAGBQJXm2W3AAoJEPU2Bp2uRE+gktUQAJMYa0vZsXtrBs7RnP8NKy4S
9A3jryx8NXzaGPDp9nc7LiXSehhwDXVD8iWy86A/eMf/AUW/hJbhIEQsc0gb2oA8
l1X6j6yUt3bP1diZMCdIj6xo22P5QhhsuLWKzy18ANF8Lg/VP7NxEeBAlc94UZdj
4O5wNK3qb1FkX79AmN4jiJQaNdRdFGMXuGpd5K8vdP1opmZdO8vKE2NF4IhaQGcE
c4vSYFbdeoo+HluC3p0MSr0/VI5iz6SdV/NxX/DnWNwSvI5UhIcB9dsRTDfmeg8W
nyHi6G8BjXlDdap3cQRFfum3CyBNDRBcmumvqR26zchbNazjDjCjx5/GvkZhtgPg
1fWxxHaNEnd44GTKzjte/mids2RMmI1i4fpNsDIGBbBFt3tDG/3E9M/IowvA9sq0
RbolK3QytZIDFug3sXef2GYir7Y4kFa/ycr9xGq1fcT5/sR8OYDsrHNDU2oxgbzy
ngXEPkWU20lXzBFdX81jfh4uVAx36HymhiJ9Qndv/8FWcMw5YJqX39qv53B1NnLI
4IogZRooI0vK4DYDeI1Wr1xhInlaPoAwoG4HFY3ZWZDIgW1hDc3KHjvDhSjYOF0L
OSqq5Y8GkUqCQIQwIfUkksS2sJlCCCf0CWL3CHgl/vwABO8fZVajjJsvw96znDrp
UHFl59QJUbsaeu/7YB+4
=qGib
-----END PGP SIGNATURE-----

--+QahgC5+KEYLbs62--

- Raw text -