David,
That is very strange. What I would do is create a new solupion with one button that has the code from your original post in it (but instead of copying just have a messagebox that states if the file was found or not). That way you can rule out any other factors, and find out if it is Novell that is causing this.

So you impersonate a different user, hmm does the impersonated user have rights to the file? (I am sure you checked that) If not I am sure it would appear that the file doesn't exist for that user.

I don't think you can destroy a static object without unloeading the assembly.

If you post your code I will take a look at it, but it would be interesting to hear from someone else running Novell. How well does impersonation work with Novell?

Einar

>Einar,
>
>Thanks for taking the time to look at this.
>
>I can run it all day without problems, so long as the files are all actually where they are supposed to be. I have checked for silly mistakes. If I run it for 5 files, it works fine. If I run it again on the same 5 files and remove the third file, the first two are copied, the third one doesn't exist and isn't copied, but then the fourth and fifth ones are reported as non-existent.
>
>I hate to add an additional ugly detail, but this code is part of a Windows service and the code below occurs inside an impersonation context. I really didn't want that to matter, but maybe I should mention it in case it does. The impersonation context is wrapped around the file transfer only.
>
>If the service is restarted after one file is reported non-existent, it does not mistakenly report existent files as not existing. I wonder if, somehow, the static File object is getting stuck and if I could force .NET to destroy the File object and recreate it every time a file didn't exist, that would be a decent workaround.
>
>Can I force the destruction of a static object by calling the destructor, somehow?