| delorie.com/archives/browse.cgi | search |
| 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 |
| 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 |
| 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
| webmaster | delorie software privacy |
| Copyright © 2019 by DJ Delorie | Updated Jul 2019 |