none
File.Copy() not returning after copying RRS feed

  • Question

  • Have a C# program that is supposed to move a file on a network share out of the way, then copy another local file in its place.  This works fine locally on my computer, but when deployed to another person's computer it copies successfully (the file size is right and all data is there), but never returns control to the program.  The program then waits and waits.  It does not throw an exception, but never proceeds to the next line of the program. Relevant code:

     try
                            {
                                File.Move(NewFile, OldFile); //This works.
                                Console.ForegroundColor = ConsoleColor.Red;
                                Console.WriteLine("Copying. Please wait until completion before opening archive."); //I see this line
                                Console.ForegroundColor = ConsoleColor.White;
                                File.Copy(CurFile, NewFile);
                                Console.WriteLine("Copied successfully. Logging success."); //I never see this line.
                                LogMessage = CurFile + " copied to " + NewFile;
                            }
                            catch (Exception g)
                            {
                                Console.ForegroundColor = ConsoleColor.Red;
                                Console.WriteLine("The archive maintenance process (2) failed: {0}", g.ToString());
                                Console.WriteLine("Is archive still open?");
                                PrimaryLog.WriteLog("Archive maintenance process (2) failed. Archive may be in use.");
                                Console.ForegroundColor = ConsoleColor.White;
                            }
    

    I see the Console.WriteLine text right before the File.Copy() but never see the Console.WriteLine text right after the File.Copy(). As I said, it doesn't throw an exception, and the file is successfully copied.  Is there perhaps some setting in Windows itself that is not returning back to the program?  Both machines are Windows 7 Pro on the same network.

    Friday, May 22, 2015 5:34 PM

Answers

  • What I discovered was that while I was waiting for the diagnostic tool rule to get set up, the program actually returns.  I was not being patient enough.  It is taking about 8 minutes for the File.Copy() to return back to the program flow even after the file appears to be in the target directory from observing the file system.  I'm guessing there's some sort of activity that is going on after the write that is taking a while and that process is not returning control to the program flow until it's completed even though the file write itself appears complete. I guess I need to be more patient. 

    I now have a diagnostic tool installed


    Friday, May 22, 2015 7:30 PM

All replies

  • It means the program is hung up, that is the program is still executing but is hanging on that file copy line.

    Out of curiosity how big is the file? Are we talking kbs, mbs, gbs, more?

    I have seen this before in the past on network shares where the share was not hosted on a windows platform but was made available via CIFS. Your best bet is to get a stack trace when this happens. You can do that by creating a memory dump of the process once it hangs using a tool like DebugDiagnostic or WinDbg. Then you can get the stack trace from that thread and see where exactly it is hanging (will be somewhere in the unmanaged portion of the stack).


    Mark as answer or vote as helpful if you find it useful | Igor

    Friday, May 22, 2015 6:00 PM
  • It is 6Gb. It is successfully copying from a Windows 7 Pro (64) to a Windows Server 2011, judging by the file size and hash.

    Will get diagnostic tool and see what I can figure out.  Thanks.

    Friday, May 22, 2015 6:11 PM
  • What I discovered was that while I was waiting for the diagnostic tool rule to get set up, the program actually returns.  I was not being patient enough.  It is taking about 8 minutes for the File.Copy() to return back to the program flow even after the file appears to be in the target directory from observing the file system.  I'm guessing there's some sort of activity that is going on after the write that is taking a while and that process is not returning control to the program flow until it's completed even though the file write itself appears complete. I guess I need to be more patient. 

    I now have a diagnostic tool installed


    Friday, May 22, 2015 7:30 PM
  • Could it be that it is a copy with verify? So after the completion the file is read in again from them target and looking if there are any errors?

    I mean it is a cross network operation. And networks are notoriously prone to transmission error.

    Saturday, May 23, 2015 9:01 AM
  • I considered that might be the case (verify), but the verification process is taking much longer than I would expect.  I also found that despite being a gigabit card and gigabit switch the line is only reading 100mbps according to the light on the switch. That would slow things down, but still should not take the 8 or so minutes it currently is, even if you're not getting full throughput on it.  It could be a network problem.  Just don't understand why it seems to copy then wait.  As I understand the old DOS verification only made sure that the file's destination could be read without error and did not actually perform any real check that would slow it down inordinately. 

    That said, I don't think it has anything to do with .NET or C#.  As I currently read the File.Copy() is a call to the Windows copy.  I'll just have to wait patiently for it to return.

    Tuesday, May 26, 2015 5:28 PM