0

I wasn't sure if this should go here or on stackoverflow.

I have an application that loads some files from a network share (the input folder), extracts certain data from them and saves new files (zips them with SharpZLib) on a different network share (output folder). This application runs fine when you open it directly, but when it is set to a scheduled task, it fails in numerous places.

This application is scheduled on a Win 2003 server.

Let me say right off the bat, the scheduled task is set to use the same login account that I am currently logged in with, so it's not because it's using the LocalSystem account. Something else is going on here.

Originally, the application was assigning a drive letter to the input folder using WNetGetConnectionA(). I don't remember why this was done, someone else on our team did that and she's gone now. I think there was some issue with using the WinZip command line with a UNC path. I switched from the WinZip command line utility to using SharpZLib because there were other issues with using the WinZip command line. Anyway, the application failed when trying to assign a drive letter with the error "connection already established." That wasn't true and even after trying WNetCancelConnection(), it still didn't work.

Then I decided to just map the drive manually on the server. Then when the app calls Directory.Exists(inputFolderPath) it returns false, even though it does exist. So, for whatever reason, I cannot read this directory from within the application. I can manually navigate to this folder in Windows Explorer and open files. The app log file shows that the user executing it on the schedule is the user I expect, not LocalSystem.

Any ideas?

1 Answer 1

0

Make sure that the task is set to "run whether logged on or not" Also check all the application has full explicit permissions (not inherited) to all files and folders.

What result code are you getting ?

1
  • Thanks. It is set to run whether logged on or not. I'm not sure about the full explicit permissions. The result code for the task is 0 because the application runs fine, but all it does is call Process.Start(otherAppPath) and that app is failing.
    – CarlB
    May 9, 2010 at 1:49

You must log in to answer this question.