场景：windowds服务器，某一个目录下文件数有数万个。
采用rsync 同步的时候 可以看出rsync 服务端卡在build filelist阶段 客户端 卡在receiving incremental file list 阶段。
考虑到一个目录下文件太多，rsync在处理文件列表的时候可能会很慢，逐结合windows下的forfiles使用
比如该文件夹路径为：
e:\webroot\upload.xxx.com\upload\upload12\2014\
DST的地址为 192.168.0.2::web_bak/webroot/upload.xxx.com/upload/upload12/2014/
SRC为 /upload.ccc.com/upload/upload12/2014/
则 同步命令可为
forfiles /p e:\webroot\upload.xxx.com\upload\upload12\2014\ /c "cmd /c rsync -ztopg /upload.ccc.com/upload/upload12/2014/@file 192.168.0.2::web_bak/webroot/upload.xxx.com/upload/upload12/2014/@file"
其中@file 是forfiles返回的变量 文件名
其他forfiles 的变量还有 @path 文件的全路径 @fname 无扩展的文件名 @ext 文件的扩展名 @relpath 文件的相对路径 @fsize 文件的大小 @fdate 文件的上一次修改日期 @ftime 文件的修改时间
――――――――――――――――――――――――――――――――――――――――――――
事实证明用forlfiles 和rsync来配置实际是forfiles遍历目录，每个文件执行一次rsync 将会导致重复的rsync连接 断开，一个目录下数十万个文件下 速度更慢，是不可行的，唯一解决了的是 以前卡在filelist的阶段，并且卡到数小时不见开始传输（估计与文件系统和单目录下文件过多导致列不出文件有关） 而用forfiles可以马上开始传输，但是没有提高效率