This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Error accessing mapped drive >2TB?


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

Attachment: pgp6hdG08b3o0.pgp
Description: PGP signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]