Home / server / Questions / 375484
Accepted
Massimo
Asked: 2012-04-01 03:47:46 +0800 CST

How to see if/when a long file copy operation actually completed?

  • 772

Having to move several very large files (VHDs) between two servers, I launched the file copy operation using Windows Explorer in a Remote Desktop session, and then closed the session without logging off, leaving the file copy to work; the next day, I logged in back and the file copy seems to have completed... but all the timestamps on the files (created, last accessed, last modified) refer to the time when I launched the copy, and I know for sure the copy operation needed several hours.

I would have expected at least the "last accessed" or "last modified" timestamps to refer to the actual time when the file copy operation ended, but looks like this isn't how it works.

How can I check (if I can at all) if the copy completed succesfully, and when?

The file size is not an indicator, as the files always get allocated the full size, even if a copy operation is interrupted.

windows files ntfs timestamp

3 Answers

  1. The best solution I know of is to use RoboCopy with the /log: option.

    • 4
  2. Best Answer

    You could use fciv to generate a hash of the file on both source and destination servers. If the hashes match, you can be as good as 100% certain that the copy was successful.

    • 2

  3. You don't state which operating system you are using, however later versions of Windows Performance Monitor could be used to give you an indication of time, if you add the bytes sent per second or bytes read per second counter for the network interface in use.

    The performance monitor graph, shows a maximum of 1000 points (Windows 7*), if accuracy isn't too important, you could set the sample frequency to 60 seconds, with a total duration of 60000 seconds (16.6 hours).

    It's not going to be terribly accurate, especially on a busy server, but might just give you a pretty good indication, especially if you couple it with other counters, e.g. logical disk activity, kernel paged pool size etc.

    If higher time accuracy or longer durations are required, you could always enable logging.

    Couple this with a checksum utility to ensure the files are identical.

    Apologies for squashing the window in the screenshot below, I didn't want the image to generate scroll bars on SF, but you can roughly see the effect of 60/60000 as detailed above. Also excuse the lack of useful data on the graph, I obviously haven't left it running for long enough, but you get the idea.

    Performance Monitor

    * I'm sure this will also be true of Windows Server 2008 R2, but don't have a box available to test this on at this moment in time.

    • 1