マイクロソフト社内で非常に多くの人に使用頂いているRichCopyなのですが、社外でも様々に取り上げられ少し驚いています。マイクロソフトはグローバルにビジネスを展開していますが、同様に社内のインフラもグローバルに展開されています。その最も重要な一つにネットワークがあるのですが、データ転送はいつも悩まされるところです。「遅延の大きいWANでいかに効率よくファイルを転送するか」、これがこのツールを作成する動機となっています。最近RichCopyを取り上げていただいたメディアは以下の通りです。
- @IT [アットマーク・アイティ （IT Proの方であれば良くご存知のインターネットメディア）
- 窓の杜 （オンラインソフトを紹介するインターネットサイト）
- 週間アスキー
ファイルコピーは単純な作業であるが故に、そこに求められるものは大きいのだと感じました。
ところで、バージョン4.0.216をリリースしました。このリリースでは以下のバグを修正しています。
1. /CSA /CSD /CSG /CSO /CSS の使用、オプションダイアログの設定内容に関わらず、セキュリティ情報がコピーされない。
2. コマンドラインから実行した場合、一部のログ情報が正しく記録されない。
3. コマンドラインから実行した場合、まれにコピー先のパスが化ける。
4. ファイルフィルタリング機能に関する記述がヘルプファイルに無い。
更新されたRichCopyをインストールする際は、必ず既存のバージョンをアンインストールしてください。新しいバージョンは、前のバージョンと同じ、以下よりダウンロードする事が出来ます。
http://download.microsoft.com/download/f/d/0/fd05def7-68a1-4f71-8546-25c359cc0842/HoffmanUtilitySpotlight2009_04.exe
I am so surprised there are so many IT professionals who are looking for rich featured file copy tools. Since RichCopy became publicly available from the Microsoft download center, I am receiving tons of emails such as questions, bug reports, feature requests. I am sorry that I am not able to respond to all of your e-mails, however I will answer most of them in my blog. Some of you may have noticed that RichCopy package on Microsoft download center has been replaced with a new build which is Version 4.0.216. There is no additional features, but the following bugs have been fixed in this release.
1. Cannot copy security information when /CSA /CSD /CSG /CSO /CSS options are specified or equivalent options are set in the option dialog.
2. Logging information is truncated when RichCopy is executed from the command line.
3. Destination path got corrupted when RichCopy is executed from the command line. (rarely happens..)
4. There is no description of file and directory filtering command parameters in the helpfile…
Currently installed RichCopy has to be removed before installing the new version.
http://download.microsoft.com/download/f/d/0/fd05def7-68a1-4f71-8546-25c359cc0842/HoffmanUtilitySpotlight2009_04.exe
One thing I found is,
There must be many users who use RichCopy to copy only updated files. Most of users assign only 1 thread for directory search; however you can dramatically accelerate the performance of source and destination comparison by assigning multiple threads, especially this works well when files are distributed to multiple directories as RichCopy assign 1 thread to each directory search, not a tree.
Here is an example. (local to local, but different storage)
(1 million files in source and destination)
Thread # for Directory Search
1 about 10 minutes
2 about 6 minutes
4 about 2 minutes
8 about 1 minutes
The Codebase of RichCopy version 4.0 is completely different from version 3.x. RichCopy 3.x consists of COM components, and the UI is a just an interface for COM components. It supports automation and shell scripting; however component registration is required, and it is not light enough on Vista because of UAC. RichCopy version 4.0 is designed to run standalone and actually without updating registries or installing multiple components. If you copy RichCopy.exe or RichCopy64.exe into your working directory, and then it should run.
32/64-bit detection: RichCopy.exe determines whether the platform is 32-bit or 64-bit. On a 64-bit platform and RichCopy64.exe is present, and then RichCopy64.exe is executed instead. Here is actual code RichCopy uses.
hKernel32 = GetModuleHandle(TEXT("kernel32.dll"));
if (hKernel32)
{
pIsWow64Process = (LPISWOW64PROCESS)GetProcAddress(hKernel32, (LPCSTR)"IsWow64Process");
pGetNativeSystemInfo = (LPGETNATIVESYSTEMINFO)GetProcAddress(hKernel32, (LPCSTR)"GetNativeSystemInfo");
if (pIsWow64Process)
(*pIsWow64Process)(GetCurrentProcess(), &fWow64);
if (pGetNativeSystemInfo)
(*pGetNativeSystemInfo)(&si); FreeModule(hKernel32);
}
else
{
GetSystemInfo(&si);
} .....
if ((sizeof(LONG_PTR) == sizeof(DWORD)) &&
(si.wProcessorArchitecture == PROCESSOR_ARCHITECTURE_AMD64))
{
Keith Combs convinced me to start blog (http://blogs.technet.com/keithcombs/). What for? I often receive e-mails asking about RichCopy, but it changed when Joshua Hoffman wrote an article about RichCopy in TechNet Magazine, April, 2009 issue. (http://technet.microsoft.com/en-us/magazine/2009.04.utilityspotlight.aspx) Keith covered this in his article, and consequently got tons of question on his blog (http://blogs.technet.com/keithcombs/archive/2009/03/22/richcopy-bulk-file-copy-tool-released-get-it-here.aspx). If I understand correctly, he screamed for help “I am not a support contact of RichCopy”, and asked me to start bloging on the TechNet.
What is RichCopy? Please visit Keith’s blog and 2009.4 issue of TechNet magazine. RichCopy was originally developed more than 10 years ago when I was working on Exchange Server 4.0 (a.k.a Touchdown project) and some other projects as a development lead. One of painful job was to copying latest build to my test machines over slow and large latency network. 10M bps was still majority of edge switches and NetBEUI as protocol at that time. RichCopy was developed to address those issues, especially to put another layer of packet transaction window. In my blogs, I will cover best practice of RichCopy configuration, QA, and I will also write about implementation for example how RichCopy supports over 64 threads while WaitForMultipleObjectEx() does not support more than 64 threads (MAXIMUM_WAIT_OBJECTS).
