permission issue??? with using System.IO.File.Exists

Question

I have a .net 4 winform application that for one computer the System.IO.File.Exists("my file path") that returns false every time.

1. The file is there.
2. If the user, using file explorer can see, open, save... the file and has complete access to the folder.
3. I made a separate winforms application that has very simple code (see below) and it works. The same file is found.

Here is the code:

If System.IO.File.Exists(txtPath.Text) Then
    lblResults.BackColor = Color.Green
    lblResults.Text = "Found"
Else
    lblResults.BackColor = Color.Red
    lblResults.Text = "No Joy"
End If

I also in the application that does not work use a 3rd party dll to read an imap mail box. Again this computer throws an error while trying to save the attachments to the root same path the error is below

saveAttachedFile:
  index: 0
  dir: Z:\XXX\Email\Attachments\6b333c68-4382-438c-99db-51a13ad1d71a\Attachments\
  ensureDir:
    createDirWin32:
      WindowsError: The system cannot find the path specified.
      WindowsErrorCode: 0x3
    --createDirWin32
    createDirWin32:
      WindowsError: The system cannot find the path specified.
      WindowsErrorCode: 0x3
    --createDirWin32
    Cannot ensure directory existence (2)
    path: Z:\XXX
  --ensureDir
  Directory does not exist and cannot be created.
  directory: Z:\CVO\Email\Attachments\6b333c68-4382-438c-99db-51a13ad1d71a\Attachments\
--saveAttachedFile

so it seems that it is a permission issue. But then again the user/computer has access to it via explorer or the 2nd .net application that only checks if the file is there?

I am not sure what else to try. Any help suggestions would be truly appreciated.

Have tried this one multiple computers in the domain and they all work. Have tried different users logging on to the computer same issue. File not found Ran the 1st Application as Administrator same issue, File not found.

    If System.IO.File.Exists(txtPath.Text) Then
        lblResults.BackColor = Color.Green
        lblResults.Text = "Found"
    Else
        lblResults.BackColor = Color.Red
        lblResults.Text = "No Joy"
    End If

System.IO.File.Exists(txtPath.Text) return False in one application but True in a second one

Answer 1

First of all, just don't call File.Exists(). There are many things that can cause file access to fail, even when File.Exists() returns true, such that all you really accomplish from calling this function is an entire extra trip to the disk... which in computer terms is slow. Very slow. Unimaginably slow. And you still have to handle the exception when it fails.

Instead, just try to open the file, and know how to handle the exception if it fails. This is one of the (very few) cases where you really should rely on exception handling for normal program control flow.

---

That out of the way... there is still possibly a permissions issue at play here, though I think the real problem is subtly different. I notice the code uses a path for a drive Z:, which is likely a drive mapped to a server somewhere, and mentions of a domain. Now I'm wonder how the code runs, because mapped drives work differently.

Mapped drives normally exist as user constructs rather than a system construct (it is possible to create mapped drives at the system level, but it's not at all normal or recommended, and they don't usually work like you expect), such that different users may have the same drive mapped to different places, or one user may map the same drive and location using different credentials to get different access, or one user may have a drive mapped, but another doesn't. And this can happen even while both users have active sessions on the computer.

The point is mapped drives normally don't exist in certain contexts, unless you do extra work to make them available. This is kind of like permissions, but not exactly; it's not you were denied access, but rather the mapped drive just doesn't exist in this context. They won't show up for Scheduled Tasks, Windows Services, Run As another user (sometimes), and other situations I'm probably forgetting. Often, even running the service or task as the same user isn't enough, if the user hasn't yet done an interactive login on the machine. In these cases, you need to use a UNC \\server\share path.

This also maps nicely to the logged error:

The system cannot find the path specified.

It doesn't say you were denied access, but rather it couldn't even find it. Almost as if the path... doesn't exist. Additionally, it explains the "cannot be created" problem; you can't create a directory on a drive that doesn't exist.