VSNet 2005 service works as expected, except for my computer being too fast/lazy ?

[Radu]

Hi. I have created a service which watches a folder and if any text
file is added to that folder runs a custom encryption scheme on it. I
add a file in that folder, and it works fine. However, when I add a
second file I have a run-time error on my "openfile" line, saying that
the file is in use by another process (of course, Explorer, which I use
to copy the file in the watched folder). The same thing happens when I
copy a series of files to that folder. If I attach to that process and
I spent a second in the debugger on the line that triggers the error,
without changing anything, and then continue (F5), everything runs fine
again with that file, which makes me believe that either Explorer does
not release the file handle fast enough, either the file watcher in my
service triggers too soon. I have added a Thread.Sleep(100) before the
starting on my encryption algorithm, but I really don't like this idea
- it's messy. Besides, even if it worked on my machine, on another
100ms might not be enough.

I could attempt to open that file several times, in a loop, with maybe
a timeout, but still, this is not elegant. Is there any (more elegant,
and cleaner) alternative, please ?

Thank you.
Alex.

 

[Rob R. Ainscough]

Your concept is VERY messy because you have no control over the file access
modes used by IE or any other application that might use in that directory.

If you encrypt the file that IE uses, IE will not longer able to use it? So
why would you do this? Are you try to manipulate cookies or something?

Anyway, might be able to open the file in a share access mode IF and ONLY IF
IE does not open the file in locked access mode. You'd have to dig deep
into the OS to remove IE's hold on a file (deeper than what .NET framework
will support).

 

[Alex Nitulescu]

No, Rob, I certainly have no malicious intents - this is simply an exercise
that I'm doing, meant to teach me how to create a fully functional,
well-behaving service )

Thanks, Alex.