CMD/BAT: Скрипт для массового копирования файлов

Похоже на задание.

Может тогда GnuWin ?

Если вам подойдёт PowerShell (больше подходит под ваши требования):

$a = Get-ChildItem -Recurse -File | where {$_.CreationTime.Month -Like ((Get-Date).Month -1 ) -and $_.CreationTime.Year -Like (Get-Date).Year}

Зачем? - Вы их потом всё равно удалите.

$a.Length                # count of objects in array
$a.FullPath | foreach {$s += $_.Length}        # $s = size in bytes

$fileswithstring1 = Select-String -Path $a.Fullname -Pattern "string1" -List
$fileswithstring1.Lenght    # Count files
$fileswithstring1.FullPath | foreach {$fileswithstring1size += $_.Length}    # Calculate filesizes

$fileswithstring2 =  Select-String -Path $a.Fullname -Pattern "string2" -List
$fileswithstring2.Lenght    # Count files
$fileswithstring2.FullPath | foreach {$fileswithstring2size += $_.Length}

$a.FullPath > "Path_to_file"
# не являюсь знатоком опций WinRar, должно быть как-то так:
winrar a -m9 -Include "Path_to_file" 123.rar

$a | Remove-Item

Если же PowerShell не подходит, далее возможны варианты:

forfiles /d +01.04.2013

Более правильный вариант для запуска скрипта 01.05.2013, как работать с датой - посмотрите в "коллекции".
Размер файла:

for %a in ("file_path_and_name") do (echo %~za)

или через dir.
Подсчёт кол-ва - через for, повсеместно встречается на форуме.
Вообще получится довольно-таки медленное и монструозное решение, если хотите пойти таким путём попытайтесь разбить каждый пункт "хотелок" на минимальные (атомарные) операции.

Ещё возможно решение средствами winrar - он умеет архивировать файлы по дате. Подойдёт, если размер данных небольшой.

Видимо да, в блоге у некто "Kazun"  было описание - "как новая возможность в v3".

Ну насчёт января ясно, а в феврале что за "грабли". Другими словами - как это выражается (можно ссылку и т.п.)?

Если память не изменяет, есть параметры -Filter и -Include - "нагляднее" маску складывать туда, а "путь оставить путём". (Правда это выглядит уже как нападки с моей стороны )

$sPrevMonthDate = ((Get-Date).AddMonths(-1)).ToString("MM.yyyy")

Get-ChildItem -Path "E:\Песочница\0244\Source\*.txt" -Recurse |`
    Where-Object {!$_.PSIsContainer} |`
        Where-Object {($_.CreationTime).ToString("MM.yyyy") -eq $sPrevMonthDate} 

По сути верно "вогнать" в $sPrevMonthDate месяц для сравнения и не заниматься этим для каждого вызова Where-Object, но зато каждый раз вызывается метод объекта и сравниваются строки. Скажем так, надо будет посмотреть как "поизящней" воплотить сравнение дат. Для объектного языка это критично, т.к. теряется основной смысл объектов.
И у PoSh есть существенный недостаток (во всяком случае для меня) - сложно рассматривать конструкции "в уме" или "на бумаге" - обязательно надо пробовать - что оно такое и как оно себя ведёт вообще.

Как-то так, без преобразования даты в строку:

$sPrevMonthDate = (Get-Date).AddMonths(-1)

Get-ChildItem -Path "E:\Песочница\0244\Source" -Filter *.txt -Recurse |`
    Where-Object {!$_.PSIsContainer} |`
        Where-Object {($_.CreationTime).Month -eq $sPrevMonthDate.Month -and ($_.CreationTime).Year -eq $sPrevMonthDate.Year} 

И ещё:

Мне так не кажется - виноваты конструкты типа:

... -Day ([System.DateTime]::DaysInMonth($dtPrevMonthDate.Year, $dtPrevMonthDate.Month))

Дольше времени требуется на анализ "а что-таки автор имел в виду на самом деле?". И я бы сказал для "детского скрипта", каким он, всё-таки, является - это "извращение".
Хотя, "оффтоп" я тут развёл, поэтому меня не покидает мысль - а не пора ли создать раздел для PoSh?

В данном случае уместнее -eq, -like "утащил" из кода над которым работаю сейчас.
Согласно документации без использования знаков подстанови ("*","?", "[", "]" и т.п.) полностью аналогичен -eq (но не -ceq - Case sensitive EQ). Точнее, что-то среднее между -Match и -Eq .

Это явно перебор , там лишь пара исправлений.
Вообще, если размышлять о "красивости", необходимо каким-то образом избавиься от конструкции (но таким образом теряем совместимость с v2):

...
Where-Object {!$_.PSIsContainer} |
...

и двойного сравнения через -and (ума не приложу как, и сам хочу понять, как сравнить строку с массивом строк - может быть поменять их местами?), а в идеале и от Get-ChildItem -Recurse - т.к. "знающие люди" говорят про низкую скорость работы (требует проверки - насколько? во сколько раз?).

1. Использование "inline dotNet" - это, конечно, фича, но не вижу смысла использовать её везде, где только можно. Логично предположить - там где "стандартное" решение невозможно и нет альтернатив, или стандартное решение и/или альтернативы "убоги" для данной задачи.

2. Зачем сравнивать по дням и мучаться с вычислением дней в месяце когда в условии чёткая формулировка "за 1 конкретный месяц" (операционки нынче умные и создать файл с датой 30.02.2013 попросту не смогут)?

В данном направлении есть интересная заметка у Vadims Pod?ns:

Также многие моменты/вещи можно "утянуть"/"подсмотреть" в блоге, например PS_FCIV, который, правда, требует допила, для того чтобы быть внешне совместимым с оригинальным fciv.exe (есть проблемы вида - "не умею обрабатывать одиночный файл, к примеру - вычислить его MD5" и "вырвиглазый вывод на консоль").

Чтож, от этого не убежишь, "все люди ошибаются, т.к. людям свойственно ошибаться". И всё требует знаний, умений и практики.
Быть "универсалом" страшная вешь - несмотря на горы знаний, "большим" специалистом всё равно не стать, посему лучше избрать свою, довольно узкую стезю и работать в её пределах, отвлекаясь лишь на поверхностное изучение как смежных, так и далёких областей.
К примеру, у меня стойкая антипатия к *Basic*, потому что "он, по обыкновению, нигде, никому не нужен" (личная "фобия" , хотя как язык для обучения, наверное, один из самых лучших).

Нет проблем, "... нет ребята, я не гордый, я согласен на медаль ...".
Качество и т.н. "нужность/необходимость" кода в коллекци просто отвратное, но не будем об этом.