Тема: Аттачи, разделение, перепаковка.

Проблема такая. Есть Бат. Есть свыше 30т. писем (4 гига база).
Есть необходимость перепаковать все в "хранить аттачи отдельно", ибо -
1 - так оно реально быстрее работает.
2 - поскольку Base Mail Dir указана в сеть, нефига по сети открывать 800 меговые tbbшники.
3 - просто такая задача из существующей базы "attach in body" сделать "атач в папке"

Путь попыток:
1. Сначала пытался найти опцию перепаковки - не нашел
2. Export - Import в новую базу (где изначально стиоит эта галочка. НО
msg|eml - бьется время поступления письма (становится на текущее) - можно сортировать по времени написания - но это неинтересно.
3. Export в Unix ящик и импорт потом оттуда. Все как надо, но обнаружился 1 интересный баг. Если у меня в базе есть 7 атачей с одинаковым именем(но текст самого письма разный) - то при импорте из такой базы я получу 1 файл attach.xls размером своим, и 6 файлов вида attache1.xls, …2.xls, ....3.xls - но размером 0 байт… Соотв-но в бате - аттачи у этих писем нулевые, несмотрибельные, и в принципе можно считать их потерянными. На 50% базы у меня на 8000 атачей вышло 1300 нулевых файлов. Поскольку почтовая переписка относится к юридической дематике, дополнениям к договорам и тд. - то потеря 10% данных критично…

Это так нада или это глюк?

Единственный правильный пункт 3… Но то с чем вы столкнулись - это расплата за позднее решение "хрань аттачи по другому" …
Когда бат так делает в момент работы, он сам правит линки на 1, 2 и т.д., а вот при импорте он аттачи переименовывает, а ссылки - нет

3-й пункт правильный где? в описании проблемы? или в описании попыток решения?

Если первое - то это очень интересно. Неужели Бат, открывая 1.2 Гиговый TBBшник через сеть работает ну хотя бы не медленнее чем на 10% от условия открытия 70 мегового TBBшника и открытия аттачей из папки по запросу? Это не сарказм, это деиствительно интересует. А если кто-нить расскажет алгоритм этой работы - то вообще класс, ибо на Бат ушли после того как аутлюк начал с сетевой базой работать ну так медленно, что ужас.

Если второе - то есть ли все таки какой-то способ это реализовать? Какой нить внешней утилитой или что-то подобное? Я конечно знаю как это сделать - unix-обратно-в бэкапе смотреть имена- сейвить файлы-и подсовывать их вместо нулевых… Но это будет очень занятно и продолжительно

Правильный - 3-й путь решения проблемы. Хотя ты ведь не думаешь, что Мыш каждый раз при открытии письма тащит все твои 1.2 ГБ через сеть? У него есть индекс, где записано, где какое письмо лежит, и он вытягивает только то, что нужно. И если письма разумных размеров, то, по-моему, особых тормозов быть не должно. Так что ты поясни, "так оно реально быстрее работает" - это твоё предположение, или поддающийся измерению и наблюдению факт?
А вообще-то, у знакомых я каждый год разделяю базы - делаю новый ящик, туда переношу сообщения, а новый год - с чистой базой, и к старым сообщениям доступ быстрый есть.