Why is .NET’s File.Open with a UNC path making excessive SMB calls?

In short, File.Open calls new FileStream() and new FileStream() does a lot of calls:

1. NormalisePath.

   String filePath = Path.NormalizePath(path, true, maxPath); // fullCheck: true
   

leads to this code:

1.a: Get full path:

    if (fullCheck) { ... 
        result = newBuffer.GetFullPathName();

GetFullPathName() calls Win32Native.GetFullPathName one or two times (depending on the lentgh of resulting path).

1.b. Trying to expand short path. Your path contains ~ char, so it looks like a candidate for a path expanding:

    if (mightBeShortFileName) {
        bool r = newBuffer.TryExpandShortFileName();

as a result, Win32Native.GetLongPathName() is called.

2. FileIoPermission.Demand() (for non-trusted only):

   // All demands in full trust domains are no-ops, so skip 
   if (!CodeAccessSecurityEngine.QuickCheckForAllDemands()) {
       ...
       new FileIOPermission(secAccess, control, new String[] { filePath }, false, false).Demand();
   

3. Open fileStream (floppy strikes back;)):

    // Don't pop up a dialog for reading from an emtpy floppy drive
   int oldMode = Win32Native.SetErrorMode(Win32Native.SEM_FAILCRITICALERRORS);
   try {
       ...
       _handle = Win32Native.SafeCreateFile(tempPath, fAccess, share, secAttrs, mode, flagsAndAttributes, IntPtr.Zero);
   

4. Win32Native.GetFileType()

Not all of them would lead to smb request, but some will do. I’ve tried to reproduce chatty requests by debugging with source step-by-step (here’s manual for enabling the .net source debugging) and checking the log after each step. Resuts are more similar to your’s first listing.
If you’re really interested in finding the real issue, you’ll have to do it yourself.

UPD Note that I’ve checked current (.net 4.5.2) behavior. It was changed multiple times since 2.0 (e.g. FileIOPermission.Demand() originally was called for full-trusted code too), so it depends:)