0

I'm encountering an odd problem that only shows up in production and only after the process has been running for days, sometimes weeks. The code triggering the error is very straight-forward. It's looking in a report directory to delete old data:

public void DeleteOldReports(){
    DateTime now=DateTime.Now;
    foreach(String filePath in 
        new DirectoryInfo(ReportPath)
            .GetFiles()
            .Where(x=>x.Name.StartsWith("webReport-",StringComparison.CurrentCultureIgnoreCase) && (now-x.LastWriteTime)>WebReportLifetime)
            .Select(x=>x.FullName)
            .ToList()
    ){File.Delete(filePath);}
}

The exception is thrown on the new DirectoryInfo(ReportPath).GetFiles() call, which is a simple file read operation.

The exception is:

System.UnauthorizedAccessException: Access to the path '\\inst7\appsupp\btc_webreports' is denied. at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath) at System.IO.FileSystemEnumerableIterator1.CommonInit() at System.IO.FileSystemEnumerableIterator1..ctor(String path, String originalUserPath, String searchPattern, SearchOption searchOption, SearchResultHandler`1 resultHandler, Boolean checkHost) at System.IO.DirectoryInfo.InternalGetFiles(String searchPattern, SearchOption searchOption) at cf.core.WebReportManager.DeleteOldReports() in WebReportManager.cs:line 26

This routine works fine for days or often weeks, but once that first exception is thrown, it'll continue throwing the exception on each access attempt. It never works again until the process is restarted.

Now, if it only happened once and then recovered, I wouldn't worry. Perhaps 'inst7' was temporarily offline. Or perhaps the domain controller or some other VM that plays a role in determining access to shares was briefly unavailable. But that's not what's happening here. It's almost as though some particular token or right that allows my process to access that path has expired or has been revoked. Restarting the process fixes the problem immediately.

Once the process enters this bad state, there's no way to regain access as far as I can tell. This, despite the fact that I can navigate to the folder in question with no problem in Windows Explorer, and furthermore, permission tests via 'View Effective Access' indicate no problem.

All VMs involved in the interaction are running Windows 2016 Server on AWS.

How can I troubleshoot this?

Best,

Festus

Festus Martingale
  • 359
  • 1
  • 2
  • 10
  • It looks like "\inst7\appsupp\btc_webreports" is a relative path. Can you check ReportPath and make sure it's a full file path such as C:\inst7\appsupp". The "current" directory in Windows can change, and this will affect all relative path queries at any time. You will want to use absolute paths whenever possible. – Jon Apr 23 '19 at 15:17
  • 1
    It's actually \\inst7 (two backslashes, as in a UNC path). I'm not sure why it's only printing with on backslash in my question. I'll see if I can fix. UPDATE: For some reason if I type my question with three consecutive backslashes it displays properly in the question. Thanks for pointing this out. – Festus Martingale Apr 23 '19 at 15:19
  • Remember that \ is an escape character in C# strings, if you want to have \\ in the path, remember to put an @"\\inst7\appsupp"; before the string. Perhaps your code is only using one slash, that's why it can't find the file. From the exception message, it looks like it's only 1 slash, unless this is a bug in the WinIOError class. – Jon Apr 23 '19 at 15:20
  • In that case, it's a network share. Can you try mapping that share to a drive letter, and use the drive letter in your code instead? Network shares can be flaky, I have had the same issues in my production code where I would get WinIOError occasionally. Using a drive letter helped. – Jon Apr 23 '19 at 15:21
  • Thanks Jon. The value for 'ReportPath' is imported from a config file, not hard-coded but I did verify that it's set to "\\inst7\appsupp\btc_webreports" – Festus Martingale Apr 23 '19 at 15:21
  • I'm open to trying a drive letter instead. That's an interesting suggestion. But drive letters aren't accessible from services, correct? – Festus Martingale Apr 23 '19 at 15:22
  • What do you mean services? A Windows Service? They can access drives. – Jon Apr 23 '19 at 15:23
  • Yes, services can access physical drives but I could've sworn I read something here once that mapped drives (e.g. mapping z:\ to \\inst7\appsupp for example), while accessible to the user who created the map, aren't accessible to a service running under a different account. Perhaps I'm not remembering correctly. I'm open to trying it. – Festus Martingale Apr 23 '19 at 15:25
  • You're right https://stackoverflow.com/questions/182750/map-a-network-drive-to-be-used-by-a-service – Jon Apr 23 '19 at 15:26
  • Maybe you have a scheduled task that copies those files every X minutes or hours to a local folder and have your service only work with the local folder. You can setup a scheduled task in Windows and use xcopy. – Jon Apr 23 '19 at 15:30
  • Yeah, there are any number of workarounds I could use and I'm certainly not dead set against that in a pinch, but am still a bit perplexed by this odd permissions issue. The fact that a single process would suddenly and permanently lose access until restart is peculiar to me. – Festus Martingale Apr 23 '19 at 15:40
  • You could try disabling the AutoDisconnect setting from net config server? https://social.technet.microsoft.com/Forums/windowsserver/en-US/bdb4021e-9eed-4639-8bfb-b9cd276f15e1/losing-access-to-shared-folder?forum=winserverfiles – Jon Apr 23 '19 at 15:43

0 Answers0