vote up 4 vote down star
2

If we have a successful build on our build server (CCNET) all ASP.Net website files are copied to the virtual directory (%output_dir%) so non-devs can see/test the latest version of the website. At the end of the build the following bat file is executed.

rmdir /s /q "%output_dir%"
mkdir "%output_dir%"
xcopy "%source_dir%*"  "%output_dir%" /e /c /i /q /-y

The problem is I find the copying slow and was wondering if there are any copy commands available in windows 2008 that are faster than xcopy? The source and destination are on the same drive. Below are the arguments we use when copying.

/e = copies directories and sub directories including empty ones.
/c = continues copying even if there are errors
/i = if destination does not exist destination is directory
/q = don't display filenames
/-y = confirm overwrite
flag
Not programming related, but belongs on ServerFault.Com, imho. – Binary Worrier Jun 16 at 12:01
I would put this question over on serverfault.com. – Jeremy Sullivan Jun 16 at 12:01

6 Answers

vote up 4 vote down

I typically use:

robocopy source dest /E /MIR

or some other variant of the parameters - perhaps /NFL /NDL /NS /NC /NP to match the "quiet"

link|flag
yep, /NP is a must for speedy robocopies – Ivo Looser Jun 16 at 12:54
when u whould create the exact same content as in the source over and over i whould use /MIR or /PURGE from the Robocopy command. – Ivo Looser Jun 16 at 12:57
vote up 4 vote down

From a performance standpoint only, xcopy or robocopy will give you similar results. I ran through a couple of tests on a Vista 64bit sp2 box to do some comparisons. All copies were performed between a internal 7200 RPM Sata II disk and an external USB 2.0 drive or on the same internal drive itself where indicated. No special setup was done (make up your own mind if that invalidates/validates the test), only to input the command into a batch file to execute. Powershell was used to capture the start and stop times. After a couple of passes here are the averages from the tools I played with:

File: 732,909,568bytes (698MB) 1 ISO file copied to different dir on same internal disk

copy     6secs  (ex. copy G:\folder1\* G:\folder2\)
xcopy    6secs  (ex. xcopy G:\folder1 G:\folder2 /I /E /Y /R)
robocopy 6secs  (ex. robocopy G:\folder1\ G:\folder2 /E /NP)
teracopy 28secs (ex. TeraCopy.exe Copy G:\folder1\ G:\folder2\)
fastcopy 19secs (ex. fastcopy.exe /auto_close G:\folder1 /to=G:\folder2)

File: 732,909,568bytes (698MB) 1 ISO file copied to external usb disk

copy     36secs (ex. copy G:\folder1\* I:\folder2\)
xcopy    35secs (ex. xcopy G:\folder1 I:\folder2 /I /E /Y /R)
robocopy 36secs (ex. robocopy G:\folder1\ I:\folder2 /E /NP)
teracopy 36secs (ex. TeraCopy.exe Copy G:\folder1\ I:\folder2\)
fastcopy 38secs (ex. fastcopy.exe /auto_close G:\folder1 /to=I:\folder2)

Files: 45,039,616bytes (42.9MB) 5 random files copied to external usb disk

copy     6secs  (ex. copy G:\folder1\* I:\folder2\)
xcopy    5secs  (ex. xcopy G:\folder1 I:\folder2 /I /E /Y /R)
robocopy 6secs  (ex. robocopy G:\folder1\ I:\folder2 /E /NP)
teracopy 12secs (ex. TeraCopy.exe Copy G:\folder1\ I:\folder2\)
fastcopy 6secs  (ex. fastcopy.exe /auto_close G:\folder1 /to=I:\folder2)

Files/Dirs: 1,087,180,800bytes (1.01GB) 27 Files/8 Dirs copied to external usb disk

copy     *Not included in test
xcopy    57secs (ex. xcopy G:\folder1 I:\folder2 /I /E /Y /R)
robocopy 58secs (ex. robocopy G:\folder1\ I:\folder2 /E /NP)
teracopy 56secs (ex. TeraCopy.exe Copy G:\folder1\ I:\folder2\)
fastcopy 60secs (ex. fastcopy.exe /auto_close G:\folder1 /to=I:\folder2)

This is by no means an exhaustive test, but just throwing a quick real world scenario at some of the more popular tools in this genre shows that your pretty safe sticking with either xcopy or robocopy (from a performance standpoint only). Also the robocopy option /NP No Progress saves you 0 time. That doesn't mean you cannot benefit from using something other than xcopy however. RoboCopy is a great example (from Wikipedia):

Robocopy is notable for capabilities above and beyond the built-in Windows copy and
xcopy commands, including the following:

  • Ability to tolerate network outages and resume copying where it previously left off (incomplete files are noted with a date stamp corresponding to 1980-01-01 and contain a recovery record so Robocopy knows from where to continue).
  • Ability to correctly copy attributes, owner information, alternate data streams, auditing information, and timestamps by default, without the need for numerous often forgotten command line switches.
  • Ability to correctly copy NTFS ACLs, (when /COPYALL provided), and to assert the Windows NT "backup right" (/B) so an administrator may copy an entire directory, including files denied readability to the administrator.
  • Persistence by default, with a programmable number of automatic retries if a file cannot be opened.
  • A "mirror" mode, which keeps trees in sync by optionally deleting files out of the destination that are no longer present in the source.
  • Ability to copy large numbers of files that would otherwise crash the built-in XCOPY utility.
  • A progress indicator on the command line that updates continuously.
  • Ability to copy long file and folder names exceeding 256 characters — up to a theoretical 32,000 characters — without errors.
link|flag
vote up 1 vote down

I found RichCopy, with it's native multi-threading to be extremely fast...

link|flag
vote up 0 vote down

Actually, by eliminating the Network, you really restricted your testing. You might wish to consider using a network share, which is going to be bulk of admin work.

Additionally, you should use FTP, and skip CIFS altogether. Eseutil.exe is another utility you could throw in there. ( an Exchange util that can be used elsewhere, along with it's four dependent dlls. )

Then I'd like to see your results.

link|flag
vote up 0 vote down

I use XCopy for the same purpose. What I also did was added another NIC to that server and put it on a separate subnet. Then made a direct connection to the server I am transferring files from. That way the 2 machines are moving the copied data via one subnet and users can still access via the second nic which is connected directly to the LAN.

link|flag
vote up 0 vote down

You say the source and destination are on the same drive, but are they both on the build server?

If the build server is the location of the source and destination, consider moving one folder or the other to another drive, maybe on another controller.

If the build server is not the location of the source and destination (build drops are not always on the server they are built on), consider creating a task on the server where the source and destination folders reside. Then just kick off that task remotely.

link|flag

Your Answer

Get an OpenID
or
never shown

Not the answer you're looking for? Browse other questions tagged or ask your own question.