Hi Jeffrey, On Oct 23 10:30, Jeffrey Altman wrote: > Lets discuss what is going on in this particular case. Apple > constructs their file namespace as the machine name representing a > virtual directory containing mount points to partitions and end user > folders. > [...] > Apple's SMB file namespace (as is also true for the /afs file namespace) > permits the crossing of mount points without the use of a DFS referral > to a share representing the root directory of the target. As a result > the Apple SMB server does expose the existence of the mount point via > the use of the RP file attribute. > [...] > ]getfileattrsex.exe r:\ > Attribute: 0x410 > Directory > Reparse Point > Size: 0x0:0 > > 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. > > ]getfileinfobyhandle.exe r:\ > Attribute: 0x410 > Directory > Reparse Point > ReparseTag: 0xa0000003 Microsoft Surrogate > Size: 0x0:0 > EOF: 0x0:0 > Links: 1 > Delete? no > Directory? yes > > 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 which can lead to confusion except for the > fact that the SMB server is clearly indicating that there is no reparse > data to read by setting the size to 0. The error status > STATUS_NOT_A_REPARSE_POINT (0xC0000275L) is what is generated when there > is no reparse data to read.
Are you saying that the file size is supposed to be non-0 if reparse data is present? The problem is, I can't reproduce this. When calling NtQueryInformationFile(FileNetworkOpenInformation) on the reparse point, the size returned in the EndOfFile member is 0, even if it's a standard directory junction created by mklink. There's no visible difference between real and faked mount point in the results of this call. I don't see how Cygwin could avoid checking the reparse data altogether in this scenario :( > Remember that there is no requirement that SMB servers expose reparse > points at all nor is there any requirement that they expose volume > information. > > While Apple's design choices do not fit with the expectations of Cygwin > they are not necessarily wrong. Well, I'm not sure. Either they don't expose the reparse point, or they should expose them in a way which matches the expectations. Cygwin is only evaluating the default Microsoft mount points and symlinks anyway, and when using those tags, they should be used as the original provider does, me thinks. > I hope this e-mail is helpful. It is, thank you! Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
pgp1P9p08nm1B.pgp
Description: PGP signature
