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=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.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@etr-usa.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@mail.gmail.com> <712A87EA-64C7-4033-BE7F-39C8C8D527EB@etr-usa.com> <20151021100328.GL5319@calimero.vinschen.de> <CB8461F5-FB0E-44D8-81BB-B52DD02AD400@etr-usa.com> <20151021162254.GC19868@calimero.vinschen.de> <169BF9F6-FF26-4073-9CC4-786882EFBAE9@etr-usa.com> <20151022083446.GW5319@calimero.vinschen.de> <B8DBF0B5-51A9-4833-92D5-CA9E08B27DEC@etr-usa.com> <20151023092007.GF5319@calimero.vinschen.de> <562A4495.5010705@secure-endpoints.com>
To: The Cygwin Mailing List <cygwin@cygwin.com>
Content-Transfer-Encoding: 8bit

On Oct 23, 2015, at 8:30 AM, Jeffrey Altman <jaltman@secure-endpoints.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