I have a program that runs as a Windows Service which is processing files in a specific folder.
Since it’s a service, it constantly monitors a folder for new files that have been added. Part of the program’s job is to perform comparisons of files in the target folder and flag non-matching files.
What I would like to do is to detect a running copy operation and when it is completed, so that a file is not getting prematurely flagged if it’s matching file has not been copied over to the target folder yet.
What I was thinking of doing was using the FileSystemWatcher to watch the target folder and see if a copy operation is occurring. If there is, I put my program’s main thread to sleep until the copy operation has completed, then proceed to perform the operation on the folder like normal.
I just wanted to get some insight on this approach and see if it is valid. If anyone else has any other unique approaches to this problem, it would be greatly appreciated.
UPDATE:
I apologize for the confusion, when I say target directory, I mean the source folder containing all the files I want to process. A part of the function of my program is to copy the directory structure of the source directory to a destination directory and copy all valid files to that destination directory, preserving the directory structure of the original source directory, i.e. a user may copy folders containing files to the source directory. I want to prevent errors by ensuring that if a new set of folders containing more subfolders and files is copied to the source directory for processing, my program will not start operating on the target directory until the copy process has completed.
What you are looking for is a typical producer/consumer scenario. What you need to do is outlined in ‘Producer/consumer queue’ section on this page. This will allow you to use multi threading (maybe span a backgroundworker) to copy files so you don’t block the main service thread from listening to system events & you can perform more meaningful tasks there – like checking for new files & updating the queue. So
on main thread do check for new filesonbackground threads perform the actual coping task. From personal experience (have implemented this tasks) there is not too much performance gain from this approach unless you are running on multiple CPU machine but the process is very clean & smooth + the code is logically separated nicely.In short, what you have to do is have an object like the following:
Then following the tutorial posted above issue a lock on the File object & the queue to update it & copy it. Using this approach you can use this type approaches instead of constantly monitoring for file copy completion.
The important point to realize here is that your service has only one instance of File object per actual physical file – just make sure you (1)lock your queue when adding & removing & (2) lock the actual File object when initializing an update.
EDIT: Above where I say “there is not too much performance gain from this approach unless” I refere to if you do this approach in a single thread compare to @Jason’s suggesting this approach must be noticeably faster due to @Jason’s solution performing very expensive IO operations which will fail on most cases. This I haven’t tested but I’m quite sure as my approach does not require IO operations open(once only), stream(once only) & close file(once only). @Jason approach suggests multiple open,open,open,open operations which will all fail except the last one.