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:content-type:mime-version:subject:from
	:in-reply-to:date:content-transfer-encoding:message-id
	:references:to; q=dns; s=default; b=Jdl1IClnPKOF3FO62HlWGb0FlA3T
	MH6Hfb5yDiUBrjhQZ8fWHkIhDv8xp3IcLp+BSWWfjs2h/HaSnlrDk9PQNAwXX5m3
	Q3eKreYlN2vwb9wFTDPyqope86as4aPSBY0as01HScU71xOlUCAaMwVUuAp33zgM
	9Qljz0ykbnXRZ7M=
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:content-type:mime-version:subject:from
	:in-reply-to:date:content-transfer-encoding:message-id
	:references:to; s=default; bh=n62HsiVm8gGbqWSnH3dZapvy8mQ=; b=Te
	sXQClwhqlwbpmZyzfqzp3t2QcT2WZjzpwD+cI31elf3D+mOCD1GAaf70AqzKwCNu
	B6tn/kT3zwhLU1rqru3UvvBX31kX+rPSudmTgwqa0VfUwvQKUzUxyg3yJgo90rIS
	EL/+wM4ZV7cPJdu1ipiyCIcrCL2vCcqObE/7XhgB0=
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=1.1 required=5.0 tests=AWL,BAYES_50,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=no version=3.3.2
X-HELO: etr-usa.com
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Subject: Re: Error accessing mapped drive >2TB?
From: Warren Young <wyml AT etr-usa DOT com>
In-Reply-To: <562A4495.5010705@secure-endpoints.com>
Date: Fri, 23 Oct 2015 16:15:05 -0600
Message-Id: <30B1BBD5-E147-4020-B31D-37475AEE9B7B@etr-usa.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>
To: The Cygwin Mailing List <cygwin AT cygwin DOT com>
X-IsSubscribed: yes
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id t9NMFKNh031640

On Oct 23, 2015, at 8:30 AM, Jeffrey Altman <jaltman AT secure-endpoints DOT com> wrote:
> 
> In this thread there appears to be a small amount of misunderstanding of
> what a reparse point is and how it should be used.

Thank you for clearing all of this up.  It was a fascinating read.

> the Apple SMB server does expose the existence of the mount point via
> the use of the RP file attribute.

Which is legal so far as it goes, right?

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

So is that wrong, or is it a valid way of shoehorning Unix filesystem behavior (mount points and such) into the SMB framework?

> 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

If Apple uses their own tags, wouldn’t that cause the Windows SMB client to be unable to understand Unix mount points, when if it comes across them?

I don’t see that the Apple SMB server really needs to report Unix mount points at the root of a share, but they could also appear in the middle of a share, at which point I assume there are important implications to SMB, equivalent to the inode uniqueness problem on Unix.

Therefore, I can see that Apple’s SMB server needs a way to tell the client that it is crossing a filesystem boundary.  The question is, is the way Apple chose  a sensible one?

> applications cannot rely on the serial numbers to distinguish
> between devices.  Instead, the applications must do as the Explorer
> Shell does and track the locations of the RP attributes in paths as they
> are encountered.

Isn’t the Explorer behavior more robust, anyway?  Are device serial numbers GUID-like, so that there is no need for central coordination to avoid collisions?  If not, I don’t see that a robust application should rely on them, anyway.

I’m not including things like the udev rules on Linux, where you can use a serial number to work out where to automount a removable volume regardless of which bus it appears on.  In that case, you’re dealing with a small number of serial numbers, so the chances of collision are small.

I don’t think Explorer has the luxury of making such assumptions because it has to work in all possible combinations of hardware and software, by its nature.  It is not possible to fix collisions by configuration, as with udev.

> While Apple's design choices do not fit with the expectations of Cygwin
> they are not necessarily wrong.

So, should I send Apple this code, or not?

  http://pastebin.com/uZdDZPgi
--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple