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=CZKLm+Pogvwj8rpZEBUOrrAz14gVDxgGbgN+Pc7y0UZzaxUUMxu0e
	WqfJBcHWRyJ2qg52WcZJV7n9rsv1DJTdd0bWDgFhAwmPhY3fc32IgOHV05q5YDdw
	67jUzY6+PBDgPHjhaB2v/DffgEo3fOK/zu0xNNMsOLv0SLqZThEYr4=
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=V5yjM3KljknrxJBsIDCa56Ln+kU=; b=OxBrmNCpcnbfEUvYy/Ar9Vls7XnW
	Nsi6LJcL39vhx8u1+mj18LydwprS32mKhSUFiDJVqtDK+BiISZepR95MUjjsFJAt
	OoqzS6laJa62GXBig3pGN99VDw7pW84Oby8GK/yrsqBCyPJ138lLGJIhFF9/AFcP
	ITmRWwf4PJdapeA=
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=-5.4 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2
X-HELO:	calimero.vinschen.de
Date:	Mon, 26 Oct 2015 12:13:34 +0100
From:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To:	cygwin AT cygwin DOT com
Subject:	Re: Error accessing mapped drive >2TB?
Message-ID:	<20151026111334.GF31990@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> <20151021100328 DOT GL5319 AT calimero DOT vinschen DOT de> <CB8461F5-FB0E-44D8-81BB-B52DD02AD400 AT etr-usa DOT com> <20151021162254 DOT GC19868 AT calimero DOT vinschen DOT de> <169BF9F6-FF26-4073-9CC4-786882EFBAE9 AT etr-usa DOT com> <20151022083446 DOT GW5319 AT calimero DOT vinschen DOT de> <B8DBF0B5-51A9-4833-92D5-CA9E08B27DEC AT etr-usa DOT com> <20151023092007 DOT GF5319 AT calimero DOT vinschen DOT de> <562A4495 DOT 5010705 AT secure-endpoints DOT com>
MIME-Version:	1.0
In-Reply-To:	<562A4495.5010705@secure-endpoints.com>
User-Agent:	Mutt/1.5.23 (2014-03-12)

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

Hi Jeffrey,

On Oct 23 10:30, Jeffrey Altman wrote:
> Lets discuss what is going on in this particular case.   Apple
> constructs their file namespace as the machine name representing a
> virtual directory containing mount points to partitions and end user
> folders.
> [...]
> Apple's SMB file namespace (as is also true for the /afs file namespace)
> permits the crossing of mount points without the use of a DFS referral
> to a share representing the root directory of the target.  As a result
> the Apple SMB server does expose the existence of the mount point via
> the use of the RP file attribute.
> [...]
> ]getfileattrsex.exe  r:\
> Attribute: 0x410
>         Directory
>         Reparse Point
> Size:      0x0:0
>=20
> Note that the size of the reparse data is zero.  There is no reparse
> data to read.  This is a UNIX mount point not an NTFS junction.
>=20
> ]getfileinfobyhandle.exe r:\
> Attribute: 0x410
>         Directory
>         Reparse Point
> ReparseTag: 0xa0000003 Microsoft Surrogate
> Size:      0x0:0
> EOF:       0x0:0
> Links:     1
> Delete?    no
> Directory? yes
>=20
> Apple should have registered with Microsoft their own reparse point tag.
>  Instead they broke the rules and used Microsoft's
> IO_REPARSE_TAG_MOUNT_POINT which can lead to confusion except for the
> fact that the SMB server is clearly indicating that there is no reparse
> data to read by setting the size to 0.  The error status
> STATUS_NOT_A_REPARSE_POINT (0xC0000275L) is what is generated when there
> is no reparse data to read.

Are you saying that the file size is supposed to be non-0 if reparse
data is present?  The problem is, I can't reproduce this.  When calling
NtQueryInformationFile(FileNetworkOpenInformation) on the reparse point,
the size returned in the EndOfFile member is 0, even if it's a standard
directory junction created by mklink.  There's no visible difference
between real and faked mount point in the results of this call.  I don't
see how Cygwin could avoid checking the reparse data altogether in this
scenario :(

> Remember that there is no requirement that SMB servers expose reparse
> points at all nor is there any requirement that they expose volume
> information.
>=20
> While Apple's design choices do not fit with the expectations of Cygwin
> they are not necessarily wrong.

Well, I'm not sure.  Either they don't expose the reparse point, or they
should expose them in a way which matches the expectations.  Cygwin is
only evaluating the default Microsoft mount points and symlinks anyway,
and when using those tags, they should be used as the original provider
does, me thinks.

> I hope this e-mail is helpful.

It is, thank you!


Corinna

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

--HCdXmnRlPgeNBad2
Content-Type: application/pgp-signature

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

iQIcBAEBCAAGBQJWLgreAAoJEPU2Bp2uRE+g9I0P+gJpN6KMXw8RXAWWWJIorFFQ
hWLu4ZhQ4A6hQCrUVKkFbnGmZ1+/Dd8ldRqdkL4fOg9k+Xspipz9Lft7Tp9EjVWL
uKktEPzU0lpNcBZbndhGq2yAyA6cNc0wIcZ9WGz0iIq/T6gK56D0Y76XIdOu0xe4
9tqcvIB+EVXK7HmRx4ASPpkjmQzcnLn/RLHW05tLHbOZuwj6+U8SJUQcfgVbzB9P
OLWpqX5WpI1jjDKfdqmT7dVIDuds6YqlFXBkNlSohbJko8WCatqo7qygu/leDDJk
XJLZhARKNK7dAR7Baoo9PiTmk7kh9XhOvxElqeGJgM2KtuqxjXju0Zj22Akj3aK7
jhmG9K2NAeEVGOT+uvMCjvMmszzht4kLlRr7uxTTelf1BuyjwpF+PNnbqDJ+/yLg
u05YiVMS+qiHxCqHN/OSm2PFAXaXZM3+BWgcCoKtUlUpC10vSy6P7OBv6p84L6vE
BIpLZ14FfOLmi8sdeBNKHKh2WZaUBMMHfioXN7PsP90+dz4XYDRaxEs8K9hmezA1
Dp4qSsqLaTbpH1RiGc+pvmNgHKUZXrRK9Y48oeZg+W0hAhJ28FtsHSFxLceCJcQp
aZRTWNdhaCIKgXOGdzKmxxVX7EyYwMFJ8so4Fu1PRnBaHpK6FMBZK0m4GFlzmpTU
CsfwNzRTsHLeGioVqUoL
=j3hI
-----END PGP SIGNATURE-----

--HCdXmnRlPgeNBad2--

- Raw text -