Core of the problem: I receive "(0x80070002) The system cannot find the file specified" for roughly 8 to 9 seconds before it can open it successfully.

In a nutshell, we have two COM components. Component A calls into Component B and asks for a UNC filename to write to - the filename returned doesn't exist yet, but the path does - it then does its work, creates and populates the file, and tells Component B its done by making another com call. At that point Component B will call MoveFile to rename the file to its "official" name.

This code has worked for (literally) years. Its works fine on win2k3. Its works fine when its running on win2k8 and points to a share on a win2k3 server. It also runs fine, if the share is actually located on the same win2k8 machine that the code is running on. But if you run it on win2k8 and point it to a share on a different win2k8 server, it fails.

Both Component A & component B exist in their own Windows Service running with as a domain admin account. The shares are configured for "Everyone/Full control" in all test environments, similarly so are the underlying folders that the share points to. All machines are in the same domain.

During debugging I realized the file actually does exist by the time I get to checking manually for it - after several iterations it occurred to me that the file doesn't "show up" until some delay passes by - so I put in the loop below in component B as shown below:

int nCounter = 0;
while (true) { 
    CFileStatus fs;
    if (CFile::GetStatus(tempname, fs)) break;
    SleepEx(100, FALSE);
    nCounter++; 
}

This code does, in fact, exit and nCounter is generally between 80 & 90 iterations when it does -- indicating the file "appears" approx 8 to 9 seconds later. Once that loop exits the code can successfully rename the file and all further processing appears to work.

I put a CFile::GetStatus in component A immediately before it calls into Component B and that indicates success - it can see the file and get its true size yet the call into component b made immediately after can not see the file until the above indicated delay passes. I have verified the pathnames are precisely the same, even though it would clearly have to be for the calls to eventually succeed after a pause of 8 to 9 seconds...

When something like this occurs I always assume there is a bug in my code until proven otherwise, but given (a) this code has executed properly for a very long time and (other than my diagnostic loop added) has not changed, and (b) it works in all environments except the win2k8 - > win2k8 share, I'm guessing there is some OS issue in here that i do not understand.

Any insight would be helpful. Thanks!