Всем еще раз привет!
в продолжение моей предыдущей темы по переименованию файлов мейл-сообщений в название темы.
http://foren.germany.ru/linux/f/21640747.html?Cat=&page=0&view=collapsed&sb=5
( отдельный привет и риспект BSD Lamer - насчет его намеков на "костыли и грабли" как грится, не так уж и не прав был!.. все только начинается... )
вынимаю тему из сообщения, отсекаю все лишнее, заменяю спец. символы на , скажем, нижнее подчеркивание - все хорошо, но если встречаются в теме эти немецкие крокозябры, пардон, умлауты и ß, то файлО не переименовывается... Точнее, в винде имя файла отображается исходным, в линуксе:
=?ISO-8859-15?Q?Pr=FCfung_neues_Storagesystem?=.eml - это Prüfung neues Storagesystem
=?UTF-8?Q?Termin_ge=C3=A4ndert__Inbetriebnahme_EVA4_TEil_1?=.eml - это Termin geändert...
локаль на самом сервере выдает:
de_DE
de_DE@euro
de_DE.iso88591
de_DE.iso885915@euro
de_DE.utf8
по идее для этого должна использоваться utf8 ?..
почитала, что виндовс использует utf16.
также что для желаемого результата нужно использовать утилиту quoted-printable.
пыталась "гуглить" и "яндексить", ничего не нашла похожего применимо к моей ситуации - хотя бы по переименовыванию файлов.
не даст ли кто вводную, с чего начать и как использовать?
Спасибо!

это да ! Сначала хотел тебе сразу в той ветке и написать, но не захотел показаться занудным.
Еще раз хочу спросить почему нельзя стартануть вторую копию групвари подсунув ему backup за какой то день и дать юзеру подключиться, вытащить свою почту
и на этом забыть о проблеме ??? Это же вроде не exchange с которыми такие дела не пройдут.
Не особо понял чего именно ты хочешь добиться, но гуглить надо наверное про sed.
вот например

Она хочет RFC 2047 декодировать (ссылку я выше дал), в sed-е мона канешно, но замахаешься

всем привет, и спасибо за ответы
BSDLamer,думаю с sed не все так просто при всем "хорошем", если у меня строка Subject, где умлауты, видится примерно так:
Subject: =?ISO-8859-15?Q?TERMIN=C4NDERUNG=3A_Ank=FCndigung_von_Wart?=
(сед-ом у меня заменяются при переименовании символы например ><:;$§&()/\^... ну и т.д. А как это расценивать?..)
ладно, я в общем спросила риторически, дело трудоемкое, в конце-концов можно и забить, пускай ищут по интуиции, их количество не перевешивает.

да х.. знает, почему.
потому как получается через Ж... все.
"чтоб дать пользователю подключиться" и достать свои мейлы - все через тот же "реконструкт" SESAM GUI.
также - регулярно ведется архивирование /var трех почтовых серверов
т.е. где лежат мыла и папки /var/spool/imap/user/<username>, оттуда и достается, остальное ты уже знаешь.

помойму вот это как раз то что нужно:
blog.php-web-developer.de/it/linux-unix-server/umlaute-sonderzeichen-linu...
http://linux.die.net/man/5/detoxrc
надо будет поизучать, как прикрутить.

там не умляуты, там rfc2047-кодировка
помочь может перл (ссылка выше)

use Encode qw(decode);
my $decoded = decode("MIME-Header", $encoded);

здесь можешь почитать
http://www.hackerwiki.org/index.php/Email_Parsing_mit_den_MIME-Tools_f%C3%BCr_Pe...
большую часть кода можно скопипастить, и потом добавить вот здесь

if($newmail_files[0]) {
  foreach(@newmail_files) {
    my $infile = $_; # dies ist der Name der aktuell bearbeiteten Email-Datei
    my $top_entity = &parse_MIME_stream($infile); # das Entity-Objekt fuer diese Email
    my $subject = &handle_Mail_header($top_entity, 'subject'); # Subject der Email
    my $from = &handle_Mail_header($top_entity, 'from'); # Absender
    my $to = &handle_Mail_header($top_entity, 'to'); # Empfaenger
    my $date = &handle_Mail_header($top_entity, 'date'); # Timestamp
    my @body = &get_body($top_entity);
  }
}

что-то типа

rename($infile, "${subject}.eml") or  
        warn "Couldn't rename $infile to ${subject}.eml: $!\n";

:)

если нет саппорта то забудь этот SESAM, я другой пример приводил.
Еще раз попытаюсь обьяснить.
Есть сервер в продакшене и есть backup-сервер который хранит например snapshots продуктивного. Снепшоты (бекапы) делаются например раз в день в 12 часов дня, снепшот является копией баз данных групвари в определенный момент.
В 13 часов юзер удаляет мейл из своего ящика.
На backup-сервере стартуются сервисы групвари со снепшотом который был сделан в 12 часов
Юзер коннектится своим клиентом к backup-серверу и видит свой ящик таким каким он был в 12 часов, и соответственно свое мыло которое он затер в 13 часов.
Юзер видит бекап в удобном и привычном для него виде, может пользоваться поиском и т.д. + юзер видит свой календарь и заметки и addressbook (чего нет в костыле) + юзер видит encrypted мыло
Юзер архивирует/експортирует удаленное мыло с backup-сервера, коннектится обратно к продуктивному и импортирует заарховорованое/експортированое мыло
все рады
есть аргументы против ?

привет!
ах, ты про идею со снапшотами!... это в общем мысль, действительно, имеет смысл продумать!
у нас имеются снапшоты для важных рабочих Ablagen, от виндовс и линукс кластеров, реализованные через svsp, презентованные от двух хостов. Они выполняются три раза в день: в 9, 12 и 15 часов.
одним из коллег был сострочено одно приложеньице, по которому при запуске выбираются нужные снапшоты и подключатся в Винвдовс=эксплорере.
аргументы против с ходу пока не найду, имею в виду, которые можно с ходу сформулировать точно, но вопросы может по ходу возникнуть.
по мне пока схема действий выглядит так: почтовик - бекап (бекапсервер) - снапшоты с бекап-сервера либо с него напрямую, либо с др хоста. Архивируется в идеале сейчас, отбросив Сезам, для мейлов партиция /var. Там где все ящики. И если насчет последнего, что ты пишешь, не представляю себе к сож-ю структуру базы данных почтовика, достаточно ли это будет прицепить клиентом снапшот, ну в виде как бы еще одного ящика, так?...

чет мне кажется мы друг друга не понимаем, или если и понимаем то только частично.
Еще пример, еще проще, самый элементарный
1) есть продуктивный сервер с OX, как я понял это все опенсорсные компоненты подточеные напильником, база мускул (MySQL).
2) есть backup-сервер на котором тоже установлен OX
3) тушим все на продуктивном сервере ( это просто для упрощения примера) например в 13:00 и коммандой cp тупо копируем например по NFS все папки с данными на backup-сервер. Тоесть делаем зеркало.
4) стартуем OX на продуктивном сервере и все есть как было, все работает
5) в 15:00 юзер на продуктивном сервере стер мыло которое получил в 7:00 и хочет его назад
6) продуктивный сервер не трогаем, там все есть как было и другие юзеры работают. Стартуем сервисы OX на backup-сервере, все должно выглядеть на нем так как это выглядело на продуктивном в 13:00, логично ?
7) говорим юзеру отключиться от продуктивного сервера и просим подключиться к backup-серверу. Что он увидит на backup-сервере ? Правильно, свой ящик каким он был в 13:00, а соответственно и мыло которое он стер.
8) юзер експортирует мыло, коннектится обратно к продуктивному серверу и импортирует мыло в свой продуктивный ящик
Теперь яснее ?
Ахтунг, это тоже костыль, но более эллегантный и простой, так как ты даешь юзеру не просто кучу текстовых файлов а полный функционал групвари, тебе же не надо придумывать колесо заново.
Ахтунг номер два, лицензия и дизайн групвари должна позволять такие приколы.
Если не уверенна, построй себе маленькое окружение и поиграйся, или хотябы выдвигай эту идею на митинге, попроси помощи. Пускай шеф бросает тебя и админа групвари на решение этой проблемы.

BSDLamer, да я тебя поняла
что похоже без полноценной копии почтовика не обойтись.
почтовик виртуальный.
поиграться так что можно попробовать.
насчет лицензий и тд это уже вопрос не ко мне, так или иначе привлекать коллегу по групваре придется, это точно.
ну и возвращаясь к теме, скриптец работает, если не брать в расчет крокозябры, но есть проблема если в восстанавливаемом каталоге встречаются один или несколько пробелов... ((( как переименовать файлы в каталогах с пробелами?.. линукс их режет на части. Т.е. он читает файлы в каталоге так: если каталог HP SEA: EVA , то HP/xxx, SEA:/xxx, EVA/xxx
точный вывод с отладкой могу похзже сбросить, помоему так... точно может ща не воспроизведу, но принцип понятен думаю.
идею с копией почтовика все равно рассмотрю, просто хочется уж продуктивно начатое "добить".

чего вы так страдаете. для этого существуют уже готовые решения. вам ведь нужно архивировать мыло не так ли? вы хотите юзверям дать возможность покапаться в этом заархивированом мыле? они должны так же иметь возможность восстановить мыло?
я вам представляю решение:
http://www.mailarchiva.com/
свободного варианта достаточно. ентрепрайс может коннектиться в аутлук.
а в общем и целом советую просто мыло по запросу клиента при условии доплаты пропускать через какой нить сервачек, который все это мыло хранит. в принципе то же самое что делает выше указаное решение, только прийдется все своими руками делать.

предидущую ветку ТС читал ?

краем глаза. понял что они хотят все на блюдечке приподнести. нах надо. юзверь сам знаем что ему нужно. + в этой системе поиск реализован хорошо. делать за юзверя, усложнять себе жизнь! :)

архивация мылa это как бэ совсем не backup. И тему лучше всю прочесть.

ну я из тех соображений, что мыло изменяется один раз. можно конечно извращаться, но я говорю о рядовом пользователе. поэтому большой разницы иметь одно и от же мыло в нескольких копиях смысла не вижу. архивации в полне достаточно.
ща посмотрю. ;)

http://foren.germany.ru/showmessage.pl?Number=21654213&Board=linux
по моему это самое главное, вызывающее гемор, не так ли? :)
а так конечно с ОХ-ом как то разбирался. интересно какой MDA используется: courier, curys. скорее всего последний. если так то там есть возможность репликации. по этому смысла трогать мыло помимо MDA не вижу.

достаточно архивации или нет, это уже второстепенный вопрос.
Backup должен быть и работать как часы.
Backup нужен для restore/recovery всего сервера, в случае если ты сервер потерял вообще. Как сам понимаешь из архива сервер не восстановить. Второе назначение backup это single item recovery или single mailbox recovery.
Будь то мыло, заметка, appointment или содержание адресной книги или вообще весь ящик одного или нескольких юзеров. Насколько я знаю в архиве хранится только мыло, все остальное ты из архива не вытащишь и из архива не восстановишь.
Надо мыло архивировать или не надо, до сих пор еще никто не знает. Закон об архивировании бизнес-мыла нарушает другие законы.
Для архивации мыла нужны отдельные и определенные ресурсы + хранить 10 лет, не у всех есть бютжет. Обычный storage там не прокатит.
Я конечно понимаю что многие хотят на этом сделать бабки. Сам давно работал на контору которая кроме всего прочего пыталась впарить такие вот продукты, пугая клиента законами, правда многого при этом не договаривала.
Кстати весь топик на самом деле вообще о другом. Тут ТС пытается изобрести заново колесо и нажить гемор. Вместо того чотбы утюжить производителя софта, который за это еще и бабло поимел. Но тут у всех ситуации индивидуальные, поэтому судить не берусь.
Еще ТС был предложен альтернативный вариант, с зеркалом продуктивного сервера. Такой вариант себя оправдал в боевых ситуациях но правдо с другим продуктом.
Такие дела...

по поводу бэкапов я не спорю! имел ввиду что бэкапить мыло я стал бы дополнительно.
по поводу производителя согласен.
по поводу ОХ не было ничего сказано. у тех клиентов, которых я знал сплошные проблемы с этой груп-тварью. с некоторых пор даже Univention предлагает как альтенативную groupware - zarafa и kolab, хотя раньше концентрировались по-моему только на ОХ.