Ошибка в одной из утилит из набора OlegON Utils : Программы OlegON

А именно, ошибка в утилите killer. Если количество дней больше 73, killer перестает стирать старые файлы.

Да, я видел сообщение в почте, прошу прощения, не успел еще проверить и посмотреть, в чем может быть загвоздка. В выходные дам ответ.

Перепроверил. Есть всего два возможных ограничения. Это
1) Длина пути к файлу - не более 255 символов
2) Количество файлов - не более 50000

никакой цифры 73 по алгоритму не встречается...

Ни одного из этих ограничений у меня нет. Сейчас я в легком замешательстве - то, что у меня не работало, когда я писал первый пост, сейчас работает, но зато не работает при другом сочетании количества файлов в папке и количества дней хранения. Продолжаю эксперементировать с проверочным батником, скоро пришлю по почте логи работы killer.exe, есть там несколько непонятных моментов.

Есть подозрение, что проблема в батнике, а не программе. Обращаю внимание, что программа работает по следующему алгоритму.
1) Если есть новый файл - добавляется в базу и записывается время.
2) Если в базе есть файл, записанное время которого разнится с текущим больше чем на указанное количество дней - он удаляется из базы и с диска.
3) Если файла нет на диске, он удаляется из базы.
Т.е. налицо связь не с временем создания или доступа к файлу (что в большинстве случаев некорректно отрабатывает), а с временем запуска утилиты и ловли ею появившихся файлов.
Предлагаю попробовать отловить баг на машине, где время идет своим чередом. Утилиты писал для себя, естественно, что проверял. Killer - самая старая и отработанная... Единственный известный баг/фича - если удалить с диска файл не удастся, то из базы файл вычистится и пойдет на второй круг. Это по разным причинам исправляться не будет.

Так ведь батник меняет системную дату и при вызове killer получает системное окружение батника, включая дату. Или я ошибаюсь?
К сожалению, проблемы наблюдаются и в рабочем режиме. Есть машины, на которых логи хранятся по пол-года и дольше. Вот на них, killer логи не удаляет.

Т.е. там цифра уже далеко не 73? Я просто опасаюсь, что где-то в батнике косяк с вызовом киллера. В остальном киллеру без разницы, сколько чего хранится... Но могут не удаляться из-за залоченности чем-то еще.

Вот это место мне не понятно как сделано. Разве не логичнее было бы делать стирание из базы только после успешного удаления с диска? Ведь если файл, допустим, залочен сейчас, то завтра он может быть не залочен и спокойно удалится.
Угу. В большинстве случаев - days=180.
Ну-у, накосячить тут - это надо умудриться:
Больше, в батнике, файл "%WorkDir%\!CurY!CurM!CurD!" нигде не фигурирует, т.е. и лочить его некому.
Это вряд ли. Логи старые и никому не нужны ;)

Насчет нужны они или нет, это надо смотреть, например, антивирусом его зажало или еще что-то. Я просто подчеркиваю примитивность алгоритма, а отсюда и его безразличие к тому, 73 или 180 там. А что если запустить утилиту и перевести сразу время без батника, на 190 дней вперед?

Легко. Перевел дату на 01.01.2009, создал файлик, запустил killer 180, перевел дату на 19.08.2009, еще раз запустил killer 180, файлик остался на месте. После первого запуска в base.dat была одна запись, после второго запуска в base.dat стало две записи - первая пустая, вторая с именем файлика.
В общем, провел я большой эксперимент и выяснилось, что удаление вообще оказалось ни причем. У киллера, оказывается, аллергия на конец марта и конец октября :) В это время он болеет и поэтому не работает :)
Детали эксперимента:
проверочный батник был настроен на цикл из 1500 дней (с 01.01.2009 по 09.02.2013), в батнике вызывался killer 10000 (десять тысяч), т.е., удаления файлов вообще не было.
В результате анализа лога работы, был выявлен список дат, в которые киллер считал, что в рабочей папке все файлы новые и фактически удваивал размер base.dat. Вот эти даты:
29.03.2009
25.10.2009
28.03.2010
31.10.2010
27.03.2011
30.10.2011
25.03.2012
28.10.2012

Есть над чем поразмыслить.