5

My program requires access to a certain UNC path, but the path is cross-domain, so depending on the machine the program is being run on, it may or may not have default credentials. Normally, a user would have to just open up explorer and type in the UNC or IP address to get a logon prompt (at which point they can type in appropriate credentials for the domain the share is on).

Is there a "clean" way to test the UNC accessibility, and if the default windows credentials are bad then prompt them for different ones?

Right now I'm using some nasty code to try to read a text file on the share, catch an IOException, and then open an "explorer.exe" Process object (hidden) to get the logon prompt. This is all contained within a loop that checks again after 10s. It sort-of works, but the solution and logic seem really undesirable.

Are my only choices really WNetUseConnection or an interop-style solution?

Jai
  • 289
  • 6
  • 15

2 Answers2

3

Check these articles:

  • Testing File Access Rights in .NET 2.0. A handy class for testing file system permissions.
  • Vexing exceptions. Eric Lippert on why pre-emptive testing is pointless (in a nutshell: there's an implicit race condition. Between the test and the actual access, some other process may change permissions, move or delete the file, or the network could drop...etc. This means you've got to deal with exceptions thrown when you try to access the resource, so you might well structure your code to deal with the problem when it actually occurs.

I've used code like this:

new FileIOPermission(FileIOPermissionAccess.Read, path).Demand();

which is supposed to throw a SecurityException if you don't have the desired access, but for paths on network drives or UNC paths, the FileIOPermission.Demand() method appears to be a no-op.

Nicholas Carey
  • 71,308
  • 16
  • 93
  • 135
  • It's not always the case that pre-emptive testing is *pointless*. Sometimes testing ahead of time can be a performance win, for example. That is, it might be cheaper to ask "hey, is it extremely likely that you're going to throw an exception?" than it is to try it and wait for the exception. This is particularly true in long multi-step processes where the whole thing could fail on the last step. Finding out ahead of time if the last step is almost certainly going to fail can save you the work of getting there. But that said, yes, you're going to have to handle the failure case regardless. – Eric Lippert Apr 21 '11 at 14:51
  • Yeah...'pointless' is probably not the best turn of phrase. If you already know the file doesn't exist/isn't accessible up front, you might want to just bail rather than doing a lot of work that will almost certainly go for naught. – Nicholas Carey Apr 21 '11 at 16:59
  • I guess my only concern is there is a lot of overhead in my program (SQL querying, user interaction, etc) before files need to be written to a share, and when my program does write to a share it's a pretty intensive process (i.e. large zip files). This could potentially lead to a 5-10m of "wasted" time on the user's part if they don't have correct access to the UNC. I am, of course, wrapping stuff in try/catch for IOExceptions, I just pray the user knows what they mean (heh). Thanks for the helpful response. – Jai Apr 22 '11 at 13:35
0

I have never done this, but what you may be asking to do is check the Access Control List (ACL) in NTFS.

I did a web search for c# and "Access Control List" and got a couple of hits that may be of interest to you. This may be cleaner, but it may not be easier that what you are already doing.

Jim
  • 2,034
  • 1
  • 22
  • 43