This is the mail archive of the
mailing list for the Cygwin project.
Re: Error accessing mapped drive >2TB?
- From: Warren Young <wyml at etr-usa dot com>
- To: The Cygwin Mailing List <cygwin at cygwin dot com>
- Date: Fri, 23 Oct 2015 16:15:05 -0600
- Subject: Re: Error accessing mapped drive >2TB?
- Authentication-results: sourceware.org; auth=none
- 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>
On Oct 23, 2015, at 8:30 AM, Jeffrey Altman <firstname.lastname@example.org> 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
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?
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple