8

I am setting out to create an app that will watch a directory for any files created. pretty straightforward time to use a filesystemwatcher. My question relates to how to utilize it. Is it common practice to use a windows service to ensure the application is always running?

i have been trying to get away from building windows services if i don't have to, but i really don't see an alternative to doing it that way in this instance. normally, i would convert my service to a console app and schedule it using windows scheduler, but that doesn't really apply in this situation.

can anyone recommend a better way of implementing the filesystemwatcher than a windows service?

thanks for any thoughts.

EDIT in response to the comments below, more specifically, i just have to watch a directory on a server, and when a new file is created, i have to move a copy of that file into a different directory on the same server, perhaps renaming it in the process.

The frequency and amount of files will be quite small. perhaps 5-10 at most in a day.

czuroski
  • 4,316
  • 9
  • 50
  • 86
  • 1
    Perhaps implement the service in a less memory hogging language/runtime and only run your C# program when it finds a new file. – CodesInChaos Oct 20 '10 at 18:27
  • 1
    @CodeInChaos - not a great idea. Implementing native FSW function is a lot more difficult, as well as the complication involved in a dual-process solution. I thought we were past the stereotypes about managed code? – Steve Townsend Oct 20 '10 at 18:32
  • 1
    Really, CodeInChaos? I'm all for efficiency, but I'm not sure your comment is particularly constructive, and I certainly don't want to be the guy digging up someone's code later where switching languages for different parts of the project was done. (That being said, I guess we all do that often...) – Brad Oct 20 '10 at 18:35
  • Your question isn't clear. You propose using FSW to ensure an application is running? – smirkingman Oct 20 '10 at 19:26

4 Answers4

3

I'm not sure yet how the file watcher works, but this is what I'm thinking: The file system fires events; I mean like NTFS must be doing that. Your file watcher hooks into those events. The file watcher probably suspends the thread it's running in until an event occurs and the event somehow wakes up the thread. A suspended thread uses pretty much very few cpu cycles (actually none) while it is suspended, so waiting for a file event costs nothing. So a polled approach wastes mucho beaucoup (that's French, it means 'a shit load') of cpu cycles but the file watcher does not. You could probably look at PerfMon to see if this is likely true.

Jelly
  • 31
  • 1
2

You should describe more about what you want to do, but typically if you have something that needs to run in the background and does not require direct user interaction, then a service often makes sense.

You can use Remoting to connect a front-end to your service as needed if you'd like.

Brad
  • 159,648
  • 54
  • 349
  • 530
  • 2
    Very true, though WCF is a better option than Remoting, which has been deprecated at this point. – Reed Copsey Oct 20 '10 at 18:27
  • Oh great... really!? Wow, I invested a lot of time recently figuring out Remoting and all of its crap. :-D Oh well... I guess I shall go learn WCF now. – Brad Oct 20 '10 at 18:32
  • WCF is pretty awesome and decently easy to pick up. You can change functionality pretty easily with configs too – Jeff LaFay Oct 20 '10 at 19:21
1

Yes, use a service for this kind of operation, but don't use filesystem watcher. If you poll for files in your service, dont use the Timer class either.

Do check to make sure the file is completed writing and is no longer locked before trying to move it.

Its trivial to poll for file changes (syntax may be off), and eliminates much of the extra programming associated with file system watcher events.

While True 'or your exit condition'
 Dim _files() as FileInfo = Directory.GetFiles(yourTargetDirectory)
 For Each _file as FileInfo In _files
  If _file.LastModifiedDate < DateTime.Now.AddMinutes(1) Then
    'move your files'
  End If
 Next

End While
Community
  • 1
  • 1
StingyJack
  • 19,041
  • 10
  • 63
  • 122
  • what you recommend as an alternative to the filesystemwatcher. – czuroski Oct 20 '10 at 18:35
  • The only non-polling alternative is `ReadDirectoryChangesW` - a lot harder to get this right, and the same reliability problems. – Steve Townsend Oct 20 '10 at 18:36
  • I had good luck so far with this FileSystemWatcher wrapper...hides several warts. http://www.codeproject.com/KB/cs/EnhancedFileSysWatcher.aspx – kenny Oct 20 '10 at 18:40
0

Using a Windows service to wrap FileSystemWatcher is perfectly fine for what you need.

FSW is the right tool for the job (native code for filesystem watching is a bear to get right), and a service is the right mechanism to deploy it given you need 'always on' operation.

The service credentials will be independent of logged-in user too, which may be useful to you.

Steve Townsend
  • 53,498
  • 9
  • 91
  • 140
  • Couldn't disagree more about FSW. It has shown to be unreliable in several situations. Ripping it out and replacing with a polling mechanisim (managed not Win32) solved all problems. – StingyJack Oct 20 '10 at 20:00