Регистрация...

Eserv Forum / E4 / Mail / "Оригинал сообщения отсутствует" при переименовании иерархии папок

wikipost // (v2)
Продукты и услуги Скачать Документация Купить Поддержка Форумы Партнёрам Статьи О компании
Последовательность воспроизведения:

1) Создаем иерахию папок: 1\2\3\4 в почтовом клиенте

.dirs.db3:
403;0;0;0;0;1;1;1297852765;1297852765;.;1;;;;;;;;;;; 404;0;0;0;0;1;1;1297852771;1297852771;.;1/2;;;;;;;;;;; 405;0;0;0;0;1;1;1297852775;1297852775;.;1/2/3;;;;;;;;;;; 406;0;0;0;0;1;1;1297852780;1297852780;.;1/2/3/4;;;;;;;;;;;

2) В каталог 4 помещаем письмо
.messages.db3:
mid;clsid;uid;flags;created_t;modified_t;lastused_t;size;parid;ip;uri;subject;tags;refs;hits;votes;body;file;hash;author;ctype;assigned;due_t;closed_t;closed_by;start_t;end_t;title;descr;rid;q;p;e; 1;1;0;8;1297852790;1297852790;1297852790;35920;0;172.16.1.88;;RE: совет;clear;0;0;0;;e:\mail\in\ekwinn\andrey.matveev\1/2/3/4\3816.414153921.1.eml;;Зелюкин Павел;;;0;;;;;;;;;;;

Особенно стОит обратить внимание на "\" и "/" в поле file="e:\mail\in\ekwinn\andrey.matveev\1/2/3/4\3816.414153921.1.eml"

3) Переименовываем каталог "2" в "222"
.dirs.db3:
403;0;0;0;0;1;1;1297852765;1297852765;.;1;;;;;;;;;;; 404;0;0;0;0;1;1;1297852771;1297852771;.;1/222;;;;;;;;;;; 405;0;0;0;0;1;1;1297852775;1297852775;.;1/2/3;;;;;;;;;;; 406;0;0;0;0;1;1;1297852780;1297852780;.;1/2/3/4;;;;;;;;;;;

Однако... думаю все очевидно само собой...

4) Смотрим что-там с индексом письма:
\1\222\3\4\.messages.db3:
mid;clsid;uid;flags;created_t;modified_t;lastused_t;size;parid;ip;uri;subject;tags;refs;hits;votes;body;file;hash;author;ctype;assigned;due_t;closed_t;closed_by;start_t;end_t;title;descr;rid;q;p;e; 1;1;0;8;1297852790;1297852790;1297852790;35920;0;172.16.1.88;;RE: совет;clear;0;0;0;;e:\mail\in\ekwinn\andrey.matveev\1/2/3/4\3816.414153921.1.eml;;Зелюкин Павел;;;0;;;;;;;;;;;
ну, как и ожидалось: "1/2/3/4" ... Встречаем "Оригинал сообщения не найден" при попытке посмотреть данное письмо другим почтовым клиентом
 
Комментарии к версии 1 (16.02.2011 13:43) [~dandy] 121a654d
Комментарии к этой версии (16.02.2011 13:45) [~dandy] b4346e72
АвторДатаТекстtags
ac16.02.2011 14:09
Да, тут до этой папки 1/2/3/4 и сообщений дело и не доходило, т.к. переименовывалась папка 1/2, и только её индекс Eserv и исправлял.
wikipost
dandy17.02.2011 09:19
т.е это ожидаемое поведение*?
wikipost
dandy17.02.2011 13:28
проверил на чистой! инсталляции Е4, проблема полностью воспроизвелась и "оригинал сообщения отсутствует" и разнонаправленные "\" и "/" в пути индекса письма
wikipost
ac17.02.2011 13:36
Верно. Я же сказал, дело до данной папки не доходит. При переименовании обрабатывается только та папка, которую переименовывали, без подпапок.
wikipost
pig17.02.2011 14:44
dandy пишет: проблема полностью воспроизвелась .... разнонаправленные "\" и "/" в пути индекса письма

А вроде я где-то видел фразу, что теперь слэши приводятся с одному виду.

ac пишет: обрабатывается только та папка, которую переименовывали, без подпапок.

IMHO, подпапки надо смотреть. Тем более, что там письма появляются только через перетаскивание.

Бредовый вариант — добавить поле-признак (или первый байт в путь), которое определяло бы, является ли путь к файлу сообщения относительным от папки или это "полный" (действительно полный или относительно EXE) путь к файту, лежащему вне папки. Хотя даже проще выходит — относительный путь к сообщению в папке есть просто имя файла, не содержащее слэшей.
Соответственно, если путь относительно текущей папки — просто на лету добавить путь в корень папки для доступа к файлу.
wikipost
ac17.02.2011 15:22
pig пишет: А вроде я где-то видел фразу, что теперь слэши приводятся с одному виду.

Да. Они как раз перед UPDATE и приводятся. И как раз до этих операций дело и не дошло. Точнее, дошло наверное, но не в рассматриваемой папке.
wikipost
ac17.02.2011 15:27
pig пишет: Хотя даже проще выходит

Я делаю проще — просто заменяю подстроки соответственно параметрам в IMAP-команде RENAME.

: EservStorage:RenameFolder { from to \ sqh -- } ." ES:RF:1 " to STR@ " {CurrentUserFolder}/{s}" STR@ DROP ." ES:RF:2 " from STR@ " {CurrentUserFolder}/{s}" STR@ DROP ." ES:RF:3 " MoveFileA 1 <> IF GetLastError DUP . THROW THEN ." ES:RF:4 " from STR@ to STR@ RenameFolder ." ES:RF:5 " to STR@ " {CurrentUserFolder}/{s}" STR@ 2DUP TYPE CR MESSAGES_DB OpenCreateDb -> sqh ." ES:RF:6 " S" UPDATE sp_messages SET file=replace(file,'\','/')" sqh db3_exec_ ." ES:RF:7 " to STR@ from STR@ " UPDATE sp_messages SET file=replace(file,'/{s}/','/{s}/')" STR@ sqh db3_exec_ ." ES:RF:8 " sqh db3_close ." ES:RF:9 " CR ;

(Эти "ES:RF:n" были добавлены для трассировки в лог, когда я Dandy тестовую версию высылал).
wikipost
pig17.02.2011 16:12
Я не вижу здесь обхода возможного поддерева папок, вложенных в переименовываемую, с аналогичной заменой базового пути.

ac пишет: replace(file,'/{s}/','/{s}/')

Чревато в случае путей вида .../mail/..../mail/..., при переименовании mail нижнего уровня. А если делать обход поддерева, то и переименование верхней mail поломает индексы в поддереве.
wikipost
ac17.02.2011 16:32
Я и не говорил, что обходит поддерево. Просто показал как делается на данный момент (с тех пор как несколько месяцев назад разбирали с Dandy этот вопрос) и про "приведение к виду". Ваш ведь совет "проще выходит" тоже касается этого пункта, а не обхода дерева. Или я не понял ваш комментарий.

Деревьев там (в базе) как таковых нет. Приведенный код меняет имена файлов в индексе папки. Чтобы "обходил дерево" нужно аналогичный UPDATE сделать еще над списком папок (в dirs.db3), а потом по всем затронутым этим update папкам пройтись и выполнить ту же операцию в каждой папке (над messages.db3).

pig пишет: Чревато в случае путей вида

Да.
wikipost
pig17.02.2011 17:24
ac пишет: Ваш ведь совет "проще выходит" тоже касается этого пункта, а не обхода дерева.

Я предложил вариант записи путей к сообщениям, при котором при переименовании папки не требуется обход поддерева, поскольку файлы, лежащие в папках, адресуются относительно самих папок.

Останется, правда, вопрос — как бороть "Оригинал сообщения отсутствует" после чистки архива, поставляющего сообщения для INBOX.
wikipost
ac17.02.2011 17:47
Но переименование самих папок поддерева в dirs.db3 все равно делать придётся. И как делать замену всех баз на предложенную вами структуру с именами без путей — это ж придётся вообще полную иерархию всех учетных записей обойти и отрезать пути, и только потом этот "автоматический" метод начнет работать при переименовании. Лучше все же доделать описанные апдейты в каждом messages.db3 — это хоть и относительно массированная, но зато крайне редкая операция — едва ли в среднем хотя бы одно переименование папки в год случается (per user).

pig пишет: Останется, правда, вопрос — как бороть "Оригинал сообщения отсутствует" после чистки архива, поставляющего сообщения для INBOX.


Я в переписке с Dandy предлагал вариант — удалять такие записи в индексе как раз в момент обнаружения отсутствия. Или вообще ничего не делать — пусть пользователь удивится и спросит у админа "что за дела", и тот ему объяснит, что нужную почту лучше в свои папки складывать, а не отращивать инбокс всю жизнь.
wikipost
dandy17.02.2011 23:46
ac пишет: Я в переписке с Dandy предлагал вариант — удалять такие записи в индексе как раз в момент обнаружения отсутствия.
при таком подходе, например, в данной проблеме, письмо просто бы исчезло из ящика пользователя, оставшись при этом (физически) на сервере, а найти его "вручную" на сервере в куче каталогов в UTF7 та еще задачка, да и помнить о таком поведении админу надо (вернее знать и понимать что к чему)
wikipost
dandy22.02.2011 08:14
В массивный апдейт от 19.02 по данной проблеме ничего не попало. СтОит ли ждать каких-то изменений в 4.27?
wikipost
dandy03.03.2011 15:51
в очередной раз ... up ...
wikipost
dandy11.03.2011 12:20
up...
wikipost
dandy16.04.2011 09:37
up...
wikipost
ac18.04.2011 17:21wikipost
dandy21.04.2011 10:39
confirmed спасибо!

из замеченного с предложенным билдом: если есть иерархия, например: \1\2\3\4\ в .dirs.db3 есть записи
1
1/2
1/2/3
1/2/3/4

в папке 4 лежит письмо

если попробовать в TB удалить всю иерархию ( каталог 1), то TB ругается сообщение, что не может удалить непустую папку и вся иерархия физически остается на сервере, но в .dirs.db3 остаются только:
1
1/2
1/2/3

т.е. запись 1/2/3/4 все равно удаляется (хотя физически остается да еще и клиенту сообщает об ошибке при удалении)
wikipost
asm28.06.2016 16:03
последняя "проблема" так же присутствует в текущих версиях
wikipost
Работает на Eserv/5.05555 (05.06.2016)