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:reply-to:message-id:to:subject :in-reply-to:references:mime-version:content-type :content-transfer-encoding; q=dns; s=default; b=XAqHXENwyg3yG8cq gu4xZbB6d5buHpRalFN9t4f5QWLYqNHkoT3ivddSYo+pdbwMtKZhv4mtJoZf6nxT /vBkbb9xUA+TRii797cEHYCd6j8ny8siDL+JWjRINpV2kSE5qE3hLguGjqywfqr7 m0/a4QqX+9DGqUITnxPj9qVtTEw= 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:reply-to:message-id:to:subject :in-reply-to:references:mime-version:content-type :content-transfer-encoding; s=default; bh=6xiszogMZ/JvTREf9DjwLW mu2Z8=; b=rWtAW7RbnWNe+b1afkAO2KDnXjB60/Edu3IJ4/KHO96gerYl/TMLLH wJ6W7Lc7UNy7NC0Gj/aIkMcMiOXwZuAfCpYPyj4T+IvAYGEa6yRGh15xXui7W542 yCPTqbd33UgTrqpPO1rfcCVHsOYvMtkKRMpOXn79qM+ua+7CTL1gM= Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , 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: Yes, score=5.2 required=5.0 tests=AWL,BAYES_95,FREEMAIL_FROM,KAM_THEBAT,MIME_BASE64_BLANKS,SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: smtp.ht-systems.ru Date: Sat, 24 Oct 2015 03:37:04 +0300 From: Andrey Repin Reply-To: cygwin AT cygwin DOT com Message-ID: <836425854.20151024033704@yandex.ru> To: Warren Young , cygwin AT cygwin DOT com Subject: Re: Error accessing mapped drive >2TB? In-Reply-To: <30B1BBD5-E147-4020-B31D-37475AEE9B7B@etr-usa.com> References: <712A87EA-64C7-4033-BE7F-39C8C8D527EB AT etr-usa DOT com> <20151021100328 DOT GL5319 AT calimero DOT vinschen DOT de> <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> <20151023092007 DOT GF5319 AT calimero DOT vinschen DOT de> <562A4495 DOT 5010705 AT secure-endpoints DOT com> <30B1BBD5-E147-4020-B31D-37475AEE9B7B AT etr-usa DOT com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-IsSubscribed: yes Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by delorie.com id t9O0oOiW017392 Greetings, Warren Young! >> 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? My understanding is that the data stored in reparse point is not intended for end user (in this case, client system's Explorer) consumption, but solely exists for the benefits of the host file system management driver. > 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? The very presence of the reparse point attribute is all that client system needs to know. The data stored in it is (supposedly) of little utility outside the host filesystem. -- With best regards, Andrey Repin Saturday, October 24, 2015 03:32:00 Sorry for my terrible english...