FileSystemWatcher.Path Exception for Network Shared Drive

Question

im using FileSystemWatcher object to retreive files from a folder.

The code works good for local machine drives/folders but throws exception when i use a NETWORK Path.

For some reason the code do not throw an exception if i start the service in debug mode. If i install it via installutil then this exception is thrown again. Maybe is there some permission issues but i don't know what...

public LevelOneValidatedWatcher(string strLevelOneFolder)
{
    FileSystemWatcher objFSW = new FileSystemWatcher();
    objFSW.Path = strLevelOneFolder; /// <<<<<<<<<<<<    EXCEPTION THROWN HERE
    objFSW.Filter = "*.zip";
    objFSW.Created += new FileSystemEventHandler(myWatcher_Created);
    objFSW.Renamed += new RenamedEventHandler(mydWatcher_Renamed);
    objFSW.EnableRaisingEvents = true;
}

System.ArgumentException was unhandled
Message=The directory name T:\INFORMATION TECHNOLOGY\bu is invalid.
Source=System
StackTrace:
at System.IO.FileSystemWatcher.set_Path(String value)
at MA.BatchTool.ServerLibrary.LevelOneValidatedWatcher..ctor(String strLevelOneFolder) in D:\Dev\Projects\MailAssurety1.1\Development\SourceCode\MA_1.1\WebServerSide\WebServerLibraries\LevelOneValidatedWatacher.cs:line 23
at MA.BatchTool.ServerLibrary.ServerJobProcessor.StartFileWatcher(Object strPath) in D:\Dev\Projects\MailAssurety1.1\Development\SourceCode\MA_1.1\WebServerSide\WebServerLibraries\ServerJobProcessor.cs:line 32
at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean ignoreSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart(Object obj)

Answer 1

Drive letter mappings are a per-interactive login setting. The exception is telling you the truth, T:\INFORMATION TECHNOLOGY\bu indeed does not exist because for sessions other than your own session (for example the session 0 that the service runs under) the drive T:\ does not get mapped anywhere. The reason it works when you debug is because when you debug you are likely running the service inside your own session instead of inside session 0.

A similar problem happens when you try to access a mapped drive from a program launched from a UAC prompt because the UAC user is considered a "different user".

Possible further reading for potential workarounds "Map a network drive to be used by a service"