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=JuM3UjDu39qYXpCqDNVfQQzh3qLRjXBJ/S5q6dpDJOpuoFYDt8iEP
	ODOBlEDbFCRd4nZ+u5rBa+FRuHOQCzd6B8RUifmmeA8pkqC+n2h65QjoAye+4OAd
	quXSACfx51TYvHt233DA/SqPKZyVIfk/424tMFz/k2qsHJ8kA+6mdI=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Date: Wed, 21 Oct 2015 12:03:28 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Error accessing mapped drive >2TB?
Message-ID: <20151021100328.GL5319@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <CA+2x6-L_pqdN6PHE0c15hcmrmB66Z75Hz95cH+dbcn4yXuVZNg AT mail DOT gmail DOT com> <712A87EA-64C7-4033-BE7F-39C8C8D527EB AT etr-usa DOT com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;	protocol="application/pgp-signature"; boundary="45wMVEkw4XUbiYON"
Content-Disposition: inline
In-Reply-To: <712A87EA-64C7-4033-BE7F-39C8C8D527EB@etr-usa.com>
User-Agent: Mutt/1.5.23 (2014-03-12)

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

On Sep 14 14:34, Warren Young wrote:
> On Sep 12, 2015, at 11:14 AM, Nem W Schlecht <nemws1 AT gmail DOT com> wrote:
> >=20
> > The only thing I can think of is that the 2nd drive is >2TB.
>=20
> The same thing happens here with a 3.1 TB Fusion drive and a 500 GB exter=
nal drive, so no, I don=E2=80=99t think the volume size is the real issue.
>=20
> I assume you are seeing the same thing that I am, that Explorer shows the=
 root contents of both drives just fine?
>=20
> When I strace=E2=80=99d an ls of one of these root shares here, I got 764=
 lines of=E2=80=A6emissions, of which this section seems the most interesti=
ng to me:
>=20
> 1051  263166 [main] ls 4720 stat64: entering
>   625  263791 [main] ls 4720 normalize_posix_path: src /p
>   609  264400 [main] ls 4720 normalize_posix_path: /p =3D normalize_posix=
_path (/p)
>   630  265030 [main] ls 4720 mount_info::conv_to_win32_path: conv_to_win3=
2_path (/p)
>   653  265683 [main] ls 4720 mount_info::cygdrive_win32_path: src '/p', d=
st 'P:\'
>   668  266351 [main] ls 4720 set_flags: flags: binary (0x2)
>   674  267025 [main] ls 4720 mount_info::conv_to_win32_path: src_path /p,=
 dst P:\, flags 0x4022, rc 0
>  1168  268193 [main] ls 4720 symlink_info::check: 0x0 =3D NtCreateFile (\=
??\P:\)
> 10641  278834 [main] ls 4720 symlink_info::check_reparse_point: NtFsContr=
olFile(FSCTL_GET_REPARSE_POINT) failed, 0xC0000275
>   839  279673 [main] ls 4720 symlink_info::check: not a symlink
>  1049  280722 [main] ls 4720 symlink_info::check: 0 =3D symlink.check(P:\=
, 0x24B620) (0x4022)
>   655  281377 [main] ls 4720 path_conv::check: this->path(P:\), has_acls(=
0)
>   640  282017 [main] ls 4720 stat_worker: got 5 error from path_conv
>   757  282774 [main] ls 4720 __set_errno: int stat_worker(path_conv&, sta=
t*):1933 setting errno 5
>   714  283488 [main] ls 4720 stat_worker: -1 =3D (\??\P:\,0x600042080)
>=20
> Why errno 5 from path_conv?

Probably because of the above

  symlink_info::check_reparse_point: NtFsControlFile(FSCTL_GET_REPARSE_POIN=
T)
  failed, 0xC0000275

This is in fact a weird error code in this scenario.

Consider that symlink_info::check_reparse_point is *only* called, if the
file to check (here "P:\") has the FILE_ATTRIBUTE_REPARSE_POINT flag
set.  So from the Windows perspective it is certainly a reparse point.

Cygwin checks the flag to allow evaluating of reparse points as symlinks.
If the flag is set, it calls symlink_info::check_reparse_point which in
turn calls

  status =3D NtFsControlFile (..., FSCTL_GET_REPARSE_POINT, ...);

to fetch the target information the reparse point points to, in POSIX
terms the symlink target.  But *this* call returns a status of 0xC0000275,
which means STATUS_NOT_A_REPARSE_POINT.  And since it's totally unexpected
that NtFsControlFile fails on a reparse point, the code sets errno to EIO.

Hang on.

The FILE_ATTRIBUTE_REPARSE_POINT flag is set but when calling a function
to fetch the reparse data it's no reparse point anymore?  How dumb is
that?

I can't reproduce this bug with my Samba drives, but it's not actually a
bug in Cygwin from my perspective.

Yeah, that observation doesn't really help, so I applied a potential
workaround to Cygwin.  If you're set up to build your own Cygwin, please
give it a try.  Otherwise I'll upload a new snapshot in the next couple of
days.


Thanks,
Corinna

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

--45wMVEkw4XUbiYON
Content-Type: application/pgp-signature

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

iQIcBAEBCAAGBQJWJ2LwAAoJEPU2Bp2uRE+gdDcP/3CGHDPVnLn4NAwBrmHNQ4RX
cUYYIU5lH+bbRADy4ZAr/y9i9yT6vlZ43pmQMDi4qrLt4PzOC/7/vH9f5pgL4cil
njMmybLWjBvkOy1/UVcLFkJh6zNbXpBc/gVJTPhkmMjkU4EJU2JLbhBjPcs6z1Oq
GiTvTbDNsF+h0Rq9wAXGQehczBOoQeNl1xivPeBvIORbKukQmYiP+Gj3Sh+3qLlm
WGiK0eCN8wwF9JV/smf+JCYhHXnUUpAp2WHM6bDm54HCl1TmyWQ0yCaoDuwkNTlO
I9M2TJ88p/692GsQ8o9OI5tuy+sUdSOE4FTmiluNXIp3lEUAOMWuCAQ2ay/eLb7t
xM3ZI58xWfSzqMggHSSMTVdSZ3ddMUGijACTinF6Wuk+HXz1qj5JB9ofVBT7HHJG
tYLkfXGAmXguOlGTzSKPUpk0sWfx8oI/95u7x+xixQm9uvXEPjD3CM/msbIUAwhR
PFFjQKtwzVoz3vBlO9MapDyM0k4F/CCVLsDTXcfzvyR2aHc+rWEO+GIgG9iRe+4U
Zek0kmARAOJMK6SOHpAuoZevZHaK7BEsTGZyd3nRdhjrUCNjlfPKjSF/bOPFtjMg
wXRXmGxlTO6S5Qk/A7NJgOEClrN49j691D8nceNNltejI4uAVtJ7ZbhibJuKPnzh
OArmbHfAF5fzv/pJl+9D
=z1AY
-----END PGP SIGNATURE-----

--45wMVEkw4XUbiYON--