1. Forum
  2. FidoNet Russia
  3. RU.GOLDED

  • Перекодировки в GoldED

    From Nil A@2:5015/46 to Cheslav Osanadze on Mon Feb 16 07:08:54 2026
    * Originally in nino.046.local
    * Crossposted in ru.golded
    Hello, Cheslav!

    Monday February 16 2026 05:46, from Cheslav Osanadze -> Oleg Artemjev:

    Лечится вот так.
    https://brorabbit.g0x.ru/pic/69906ebb.jpg
    а какой хоткей на выбор перекодировок в деде?
    Ctrl-J, кажется.

    Подтверждаю, хотя может быть всё перенастроено.
    Чтобы список был наваристым, нужно много XlatCharSet прописать.
    а скрине в джипеге видно, что использовалась CP866->CP866 перекодировка. Это как раз тот случай, когда у Стаса в конфиге был готовый костыль.

    Best Regards, Nil
    --- GoldED+/LNX 1.1.5-b20250409
    * Origin: Gemini can make mistakes, so double-check it (2:5015/46)
  • From Cheslav Osanadze@2:6078/80 to Nil A on Mon Feb 16 06:27:37 2026
    Привет Nil!

    16 Фев 26 07:08, Nil A -> Cheslav Osanadze:

    Лечится вот так.
    https://brorabbit.g0x.ru/pic/69906ebb.jpg
    а какой хоткей на выбор перекодировок в деде?
    Ctrl-J, кажется.

    Подтверждаю, хотя может быть всё перенастроено.
    Чтобы список был наваристым, нужно много XlatCharSet прописать.
    а скрине в джипеге видно, что использовалась CP866->CP866
    перекодировка. Это как раз тот случай, когда у Стаса в конфиге был
    готовый костыль.

    У меня такая строка в выборе есть, но кодировку оно не исправило.


    Cheslav.


    ... Трое в молодке, не считая собаки.
    ---
    * Origin: ,,, (2:6078/80)
  • From Konstantin Simonov@2:5000/118 to Cheslav Osanadze on Mon Feb 16 11:47:22 2026

    Hi, Cheslav!

    Monday February 16 2026 06:27, Cheslav Osanadze (2:6078/80) => Nil A:

    Подтверждаю, хотя может быть всё перенастроено.
    Чтобы список был наваристым, нужно много XlatCharSet прописать.
    а скрине в джипеге видно, что использовалась CP866->CP866
    перекодировка. Это как раз тот случай, когда у Стаса в конфиге был
    готовый костыль.
    У меня такая строка в выборе есть, но кодировку оно не исправило.

    Зачем тебе, под Windowz, где и так CP866, нужны какие-то перекодировки?
    А входящая почта тоже в CP866. Я эти перекодировки давно убрал.


    Sincerely yours, Konstantin.

    --- GoldED+/W32-MINGW 1.1.5-b20250409 WinNT 6.2.9200 iP-III
    * Origin: Something 2:5000/100.99 2:5000/115.15 2:5000/111.11 (2:5000/118)
  • From Cheslav Osanadze@2:6078/80 to Konstantin Simonov on Mon Feb 16 07:05:09 2026
    Привет Konstantin!

    16 Фев 26 11:47, Konstantin Simonov -> Cheslav Osanadze:

    Подтверждаю, хотя может быть всё перенастроено.
    Чтобы список был наваристым, нужно много XlatCharSet прописать.
    а скрине в джипеге видно, что использовалась CP866->CP866
    перекодировка. Это как раз тот случай, когда у Стаса в конфиге
    был готовый костыль.
    У меня такая строка в выборе есть, но кодировку оно не исправило.

    Зачем тебе, под Windowz, где и так CP866, нужны какие-то
    перекодировки? А входящая почта тоже в CP866. Я эти перекодировки
    давно убрал.

    В оригинале это был ответ на то, как разглядеть БОПЮ, которая пришла через NNTP гейт в эху.



    Cheslav.


    ... Мальвина - девочка с голyбыми...
    ---
    * Origin: ,,, (2:6078/80)
  • From Nil A@2:5015/46 to Konstantin Simonov on Mon Feb 16 08:17:02 2026
    * Originally in ru.golded
    * Crossposted in nino.046.local
    Hello, Konstantin!

    Monday February 16 2026 11:47, from Konstantin Simonov -> Cheslav Osanadze:

    Чтобы список был наваристым, нужно много XlatCharSet прописать.
    а скрине в джипеге видно, что использовалась CP866->CP866
    перекодировка. Это как раз тот случай, когда у Стаса в конфиге
    был готовый костыль.
    У меня такая строка в выборе есть, но кодировку оно не исправило.

    Зачем тебе, под Windowz, где и так CP866, нужны какие-то
    перекодировки? А входящая почта тоже в CP866. Я эти перекодировки
    давно убрал.

    Сорян, я тред в профильную эху угнал. Там сырбор был про бажок в InterSquish, когда он кодировку корячит.

    По факту, покойный Одинн, тогда ещё планировал своим редактором читать емейлы и пр. по RFC.
    Когда в клуджах идёт инфа о кодировке, то голдед её хавает надёжнее, чем по FTN, пример "@RFC-Content-Type: text/plain; charset="koi8-r".
    Да, это скорее всего бажок надо в Голдед завести. Хотя. Если мы дефолтово сидим в емейлах, то не бажок.

    А ты, мой юный друг, используешь golded для чтения емейлов или фидо-мейлов? ужное подчеркнуть.

    Best Regards, Nil
    --- GoldED+/LNX 1.1.5-b20250409
    * Origin: Gemini can make mistakes, so double-check it (2:5015/46)
  • From Konstantin Simonov@2:5000/118 to Cheslav Osanadze on Mon Feb 16 12:46:24 2026

    Hi, Cheslav!

    Monday February 16 2026 07:05, Cheslav Osanadze (2:6078/80) => Konstantin Simonov:

    Зачем тебе, под Windowz, где и так CP866, нужны какие-то
    перекодировки? А входящая почта тоже в CP866. Я эти перекодировки
    давно убрал.
    В оригинале это был ответ на то, как разглядеть БОПЮ, которая
    пришла через NNTP гейт в эху.

    Тебя не должны волновать чужие проблемы, пусть беспокоится тот, кто такие сообщения посылает. А БОПЮ надо не разглядывать, а удалять.


    Sincerely yours, Konstantin.

    --- GoldED+/W32-MINGW 1.1.5-b20250409 WinNT 6.2.9200 iP-III
    * Origin: Something 2:5000/100.99 2:5000/115.15 2:5000/111.11 (2:5000/118)
  • From Konstantin Simonov@2:5000/118 to Nil A on Mon Feb 16 12:54:48 2026

    Hi, Nil!

    Monday February 16 2026 08:17, Nil A (2:5015/46) => Konstantin Simonov:

    Зачем тебе, под Windowz, где и так CP866, нужны какие-то
    перекодировки? А входящая почта тоже в CP866. Я эти перекодировки
    давно убрал.
    Сорян, я тред в профильную эху угнал. Там сырбор был про бажок в InterSquish, когда он кодировку корячит.

    Хорошо, только это не должно беспокоить тех, кого не касается, не все сообщения обзательно надо читать. Пусть пользователи линуксов обсуждают.

    А ты, мой юный друг, используешь golded для чтения емейлов или фидо-мейлов? ужное подчеркнуть.

    Спасибо за "юный друг". Юность сейчас до 70 лет?


    Sincerely yours, Konstantin.

    --- GoldED+/W32-MINGW 1.1.5-b20250409 WinNT 6.2.9200 iP-III
    * Origin: Something 2:5000/100.99 2:5000/115.15 2:5000/111.11 (2:5000/118)
  • From Cheslav Osanadze@2:6078/80 to Konstantin Simonov on Mon Feb 16 08:24:00 2026
    Привет Konstantin!

    16 Фев 26 12:46, Konstantin Simonov -> Cheslav Osanadze:

    Зачем тебе, под Windowz, где и так CP866, нужны какие-то
    перекодировки? А входящая почта тоже в CP866. Я эти
    перекодировки давно убрал.
    В оригинале это был ответ на то, как разглядеть БОПЮ, которая
    пришла через NNTP гейт в эху.

    Тебя не должны волновать чужие проблемы, пусть беспокоится тот, кто
    такие сообщения посылает. А БОПЮ надо не разглядывать, а удалять.

    Именно так я и поступил.



    Cheslav.


    ... Ява - сигареты, выпyскаемые по лицензии SUN Microsystems
    ---
    * Origin: ,,, (2:6078/80)
  • From Nil A@2:5015/46 to Cheslav Osanadze on Mon Feb 16 09:39:34 2026
    Hello, Cheslav!

    Monday February 16 2026 08:24, from Cheslav Osanadze -> Konstantin Simonov:

    В оригинале это был ответ на то, как разглядеть БОПЮ, которая
    пришла через NNTP гейт в эху.

    За наблюдательность к тирлайну +1 в карму.

    Тебя не должны волновать чужие проблемы, пусть беспокоится тот,
    кто такие сообщения посылает. А БОПЮ надо не разглядывать, а
    удалять.

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

    Именно так я и поступил.

    А Стас знал решение :-)
    е самое оптимальное, так сказать, но рабочее.

    Best Regards, Nil
    --- GoldED+/LNX 1.1.5-b20250409
    * Origin: Gemini can make mistakes, so double-check it (2:5015/46)
  • From Cheslav Osanadze@2:6078/80 to Nil A on Mon Feb 16 09:06:59 2026
    Привет Nil!

    16 Фев 26 09:39, Nil A -> Cheslav Osanadze:

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

    Именно так я и поступил.

    А Стас знал решение :-)
    е самое оптимальное, так сказать, но рабочее.

    а самом то деле, это проблема пишущего - писать в том виде, в котором читающий поймёт текст без излишних приседаний.

    А то так можно и на суахили строчить в эхи, а там - пусть разбираются.:)

    Cheslav.


    ... Когда идёшь до конца не удивляйся, что конец приближается.
    ---
    * Origin: ,,, (2:6078/80)
  • From Dima Krylov@2:5020/570.1 to Konstantin Simonov on Mon Feb 16 17:42:12 2026
    Привет тебе, Konstantin!

    Kaк-тo нa дняx (16 фев 26) Konstantin Simonov пишeт к Cheslav Osanadze...

    [ ... ]

    Тебя не должны волновать чужие проблемы, пусть беспокоится тот, кто
    такие сообщения посылает. А БHОПHЮ надо не разглядывать, а удалять.
    ┌─┐
    │√│HРАВИТСЯ
    └─┘


    --- GoldED-NSF
    * Origin: ... паясничать в ru.golded (2:5020/570.1)
  • From Stas Mishchenkov@2:460/5858 to Nil A on Tue Feb 17 23:07:38 2026
    Hi Nil!

    16 Feb 26 09:39, Nil A -> Cheslav Osanadze:

    А Стас знал решение :-)

    А, вот, обнаружил я проблему, которую не знаю, как решать пока. Если в OPUS Msg Base дед удаляет сообщение, то он не правит ластриды. Если ластрид _другого_ пользователя указывает на удалённое сообщение с большим номером, чем существующие, то так и останется. Если новые сообщения будут тоже с меньшим номером, то они для другого пользователя будут считаться прочитанными, а это не правильно и чревато. а сколько я понимаю, починить это не трудно.

    Have nice nights.
    Stas Mishchenkov.

    --- Ревновать женщину без повода - глупо, а если есть повод, то поздно.
    * Origin: Lame Users Breeding. Simferopol, Crimea. (2:460/5858)
  • From Oleg Artemjev@2:6078/80.1354 to Nil A on Mon Feb 16 15:46:31 2026
    Привет, Nil!

    16 фев 26 07:08, Nil A -> Cheslav Osanadze:
    Лечится вот так.
    https://brorabbit.g0x.ru/pic/69906ebb.jpg
    а какой хоткей на выбор перекодировок в деде?
    Ctrl-J, кажется.

    Подтверждаю, хотя может быть всё перенастроено.
    Чтобы список был наваристым, нужно много XlatCharSet прописать.
    а скрине в джипеге видно, что использовалась CP866->CP866
    перекодировка. Это как раз тот случай, когда у Стаса в конфиге был
    готовый костыль.
    А покажите кто нить кусок конфига чтоб как на картинке чтобы можно было скопипастить:

    ---команда для копипасты:---
    grep XlatCharSet `find ~ -name golded.cfg`
    ---------------------------

    С наилучшими пожеланиями, Oleg.

    --- -Уютно у вас, а только странно. И солнца мало.
    * Origin: А мы народ трудящийся... (2:6078/80.1354)
  • From Oleg Artemjev@2:6078/80.1354 to Konstantin Simonov on Mon Feb 16 21:37:10 2026
    Привет, Konstantin!

    16 фев 26 12:46, Konstantin Simonov -> Cheslav Osanadze:
    Зачем тебе, под Windowz, где и так CP866, нужны какие-то
    перекодировки? А входящая почта тоже в CP866. Я эти
    перекодировки давно убрал.
    В оригинале это был ответ на то, как разглядеть БОПЮ, которая
    пришла через NNTP гейт в эху.

    Тебя не должны волновать чужие проблемы, пусть беспокоится тот, кто
    такие сообщения посылает. А БОПЮ надо не разглядывать, а удалять.
    А я предпочитаю уметь такое прочесть.

    С наилучшими пожеланиями, Oleg.

    --- -Уютно у вас, а только странно. И солнца мало.
    * Origin: А мы народ трудящийся... (2:6078/80.1354)
  • From Konstantin Simonov@2:5000/118 to Oleg Artemjev on Wed Feb 18 21:59:36 2026

    Hi, Oleg!

    Monday February 16 2026 21:37, Oleg Artemjev (2:6078/80.1354) => Konstantin Simonov:

    В оригинале это был ответ на то, как разглядеть БОПЮ, которая
    пришла через NNTP гейт в эху.
    Тебя не должны волновать чужие проблемы, пусть беспокоится тот, кто
    такие сообщения посылает. А БОПЮ надо не разглядывать, а удалять.
    А я предпочитаю уметь такое прочесть.

    Зачем? Если кто-то шлет БОПЮ, значит он не очень-то хочет, чтобы этот текст читали, иначе бы он сделал все по-человечески. В крайнем случае сам бы перед отправкой расшифровал.

    у если тебе больше нечем заняться, можешь развлекаться расшифровкой.


    Sincerely yours, Konstantin.

    --- GoldED+/W32-MINGW 1.1.5-b20250409 WinNT 6.2.9200 iP-III
    * Origin: Something 2:5000/100.99 2:5000/115.15 2:5000/111.11 (2:5000/118)
  • From Oleg Artemjev@2:6078/80.1354 to Konstantin Simonov on Thu Feb 19 12:19:11 2026

    *** Ответ на сообщение из carbonArea (Карбонка не пустая).

    Привет, Konstantin!

    18 фев 26 21:59, Konstantin Simonov -> Oleg Artemjev:
    В оригинале это был ответ на то, как разглядеть БОПЮ, которая
    пришла через NNTP гейт в эху.
    Тебя не должны волновать чужие проблемы, пусть беспокоится тот,
    кто такие сообщения посылает. А БОПЮ надо не разглядывать, а
    удалять.
    А я предпочитаю уметь такое прочесть.

    Зачем? Если кто-то шлет БОПЮ, значит он не очень-то хочет, чтобы
    этот текст читали, иначе бы он сделал все по-человечески. В крайнем
    случае сам бы перед отправкой расшифровал.

    у если тебе больше нечем заняться, можешь развлекаться расшифровкой.
    Если у человека что-то криво настроено и он мне мылом пришлет бнопню я
    хочу прочесть, а не писать I cannot read this due to recoding problem.
    Чтобы получить ответ ещё спустя день два транслитом.

    Можно было бы и прочитать и подсказать что человеку надо поправить.

    А послать в /dev/null всегда проще.

    С наилучшими пожеланиями, Oleg.

    --- -Уютно у вас, а только странно. И солнца мало.
    * Origin: А мы народ трудящийся... (2:6078/80.1354)
  • From Konstantin Simonov@2:5000/118 to Oleg Artemjev on Thu Feb 19 22:46:38 2026

    Hi, Oleg!

    Thursday February 19 2026 12:19, Oleg Artemjev (2:6078/80.1354) => Konstantin Simonov:

    у если тебе больше нечем заняться, можешь развлекаться расшифровкой.
    Если у человека что-то криво настроено и он мне мылом пришлет бнопню я хочу прочесть, а не писать I cannot read this due to recoding problem. Чтобы получить ответ ещё спустя день два транслитом.
    Можно было бы и прочитать и подсказать что человеку надо поправить.

    етмейлом конечно стоит помочь, но здесь не нетмейл и нет смысла тратить время на расшифровку БОПИ.


    Sincerely yours, Konstantin.

    --- GoldED+/W32-MINGW 1.1.5-b20250409 WinNT 6.2.9200 iP-III
    * Origin: Something 2:5000/100.99 2:5000/115.15 2:5000/111.11 (2:5000/118)
  • From Nil A@2:5015/46 to Konstantin Simonov on Fri Feb 20 10:08:38 2026
    Hello, Konstantin!

    Thursday February 19 2026 22:46, from Konstantin Simonov -> Oleg Artemjev:

    етмейлом конечно стоит помочь, но здесь не нетмейл и нет смысла
    тратить время на расшифровку БОПИ.

    бОПЯ починена в Голдеде. Суть проблема уже изложил в предыдущем письме. Заняло несколько минут, ИИ починил по вот такому промту, и ещё мне минут 10 чтобы потом разобраться и сделать код-ревью.

    ===
    GoldEd uses the `XlatCharSet` config parameter to specify the encoding conversion map file. This allows to convert between SBCS like KOI8-R and CP866. GoldEd will search for `CHRS` kludge in messages and will convert to `XLATLOCALSET` encoding if different and the map is available.
    There is a bug when GoldEd will read the RFC header like `@RFC-Content-Type: text/plain; charset="koi8-r";` and will treat the source encoding as `koi8-r`, though the FTN encoding is specified as `@CHRS: CP866 2`.
    Can you find where in source code the RFC-based encoding is read and how to fix that `CHRS` kludge is preferred over RFC header?
    ===

    Сам пач ниже. По сути один IF добавлен и весь блок просто вправо сдвинут. Применя можно через "git am"

    0001-Fix-Prefer-CHRS-kludge-over-RFC-Content-Type-charset.patch
    ===
    From f03f43c8ff676879f4b62ea800ad2a1124808d88 Thu Apr 10 22:48:31 2025
    From: Nil Alexandrov <nil.alexandrov@gmail.com>
    Date: Fri, 20 Feb 2026 02:02:45 -0500
    Subject: [PATCH] Fix: Prefer CHRS kludge over RFC Content-Type charset

    GoldEd+ would use the Content-Type: ... charset=... from the RFC header
    even if a CHRS kludge was present. However, in FTN practice, the CHRS
    kludge is expected to take precedence if both are present.
    -+-
    golded3/geline.cpp | 24 ++++++++++++++----------
    1 file changed, 14 insertions(+), 10 deletions(-)

    diff --git a/golded3/geline.cpp b/golded3/geline.cpp
    index f4ad6f2..762e6bc 100644
    --- a/golded3/geline.cpp
    +++ b/golded3/geline.cpp
    @@ -2478,19 +2478,23 @@ void MakeLineIndex(GMsg* msg, int margin, bool getvalue, bool header_recode)
    strxcpy(chsbuf, strrword(mime_charset+8), sizeof(chsbuf));
    if(striinc("8859", chsbuf))
    ISO2Latin(chsbuf, chsbuf);
    - chslev = LoadCharset(chsbuf, CFG->xlatlocalset);
    - if(not chslev)
    + // Only set from RFC charset if not already set by CHRS/CHARSET kludge
    + if (*msg->charset == NUL)
    {
    - strxcpy(chsbuf, AA->Xlatimport(), sizeof(chsbuf));
    chslev = LoadCharset(chsbuf, CFG->xlatlocalset);
    + if(not chslev)
    + {
    + strxcpy(chsbuf, AA->Xlatimport(), sizeof(chsbuf));
    + chslev = LoadCharset(chsbuf, CFG->xlatlocalset);
    + }
    + if(chslev)
    + {
    + level = msg->charsetlevel = chslev;
    + strcpy(msg->charset, chsbuf);
    + }
    + if(*msg->charset == NUL)
    + strcpy(msg->charset, chsbuf);
    }
    - if(chslev)
    - {
    - level = msg->charsetlevel = chslev;
    - strcpy(msg->charset, chsbuf);
    - }
    - if(*msg->charset == NUL)
    - strcpy(msg->charset, chsbuf);
    gotmime = true;
    }
    else if(check_multipart(ptr, boundary))
    --
    2.53.0

    ===

    Best Regards, Nil
    --- GoldED+/LNX 1.1.5-b20250409
    * Origin: Gemini can make mistakes, so double-check it (2:5015/46)
  • From Stas Mishchenkov@2:460/5858 to Nil A on Fri Feb 20 10:37:32 2026
    Hi Nil!

    20 Feb 26 10:08, Nil A -> Konstantin Simonov:

    етмейлом конечно стоит помочь, но здесь не нетмейл и нет смысла
    тратить время на расшифровку БОПИ.

    бОПЯ починена в Голдеде. Суть проблема уже изложил в предыдущем письме. Заняло несколько минут, ИИ починил по вот такому промту, и ещё мне минут 10 чтобы потом разобраться и сделать код-ревью.

    Сделай то же самое с ластридами, плиз. Совсем хорошо будет.

    Have nice nights.
    Stas Mishchenkov.

    --- Очереди в поликлиниках отсеивают тех, кто может и сам дома полечиться.
    * Origin: Lame Users Breeding. Simferopol, Crimea. (2:460/5858)
  • From Nil A@2:5015/46 to Stas Mishchenkov on Fri Feb 20 10:55:04 2026
    Hello, Stas!

    Tuesday February 17 2026 23:07, from Stas Mishchenkov -> Nil A:

    А, вот, обнаружил я проблему, которую не знаю, как решать пока. Если в OPUS Msg Base дед удаляет сообщение, то он не правит ластриды. Если ластрид _другого_ пользователя указывает на удалённое сообщение с
    большим номером, чем существующие, то так и останется. Если новые сообщения будут тоже с меньшим номером, то они для другого
    пользователя будут считаться прочитанными, а это не правильно и
    чревато. а сколько я понимаю, починить это не трудно.

    Как в OPUS Msg хранятся ластриды, я спек на найду сходу.
    Сделал msg область в голдеде, он создал в каталоге файл lastread 2 байта, видимо в Little-Endian номер сообщения. А если будет много пользователей, то это как Squish ID, типа индекс в этом файле?

    Best Regards, Nil
    --- GoldED+/LNX 1.1.5-b20250409
    * Origin: Gemini can make mistakes, so double-check it (2:5015/46)
  • From Nil A@2:5015/46 to Stas Mishchenkov on Sat Feb 21 08:27:18 2026
    Hello, Stas!

    Tuesday February 17 2026 23:07, from Stas Mishchenkov -> Nil A:

    А, вот, обнаружил я проблему, которую не знаю, как решать пока. Если в OPUS Msg Base дед удаляет сообщение, то он не правит ластриды. Если ластрид _другого_ пользователя указывает на удалённое сообщение с
    большим номером, чем существующие, то так и останется. Если новые сообщения будут тоже с меньшим номером, то они для другого
    пользователя будут считаться прочитанными, а это не правильно и
    чревато. а сколько я понимаю, починить это не трудно.

    Посмотрел. Обновление lastread происходит при _выходе_ из арии, не важно для какой базы, логика одинаковая, и ластриды обновляются только для _текущего_ пользователя.
    Такой подход работает для Squish и JAM в режиме "soft" удаления. В OPUS/Msg сообщения удаляются всегда по-сути "hard", причём могут переиспользоваться старые номера - тут и возникает описанная тобой проблема.

    Я посмотрел код Хаски утилиты sqpack, и при перепаковки баз, если есть удалённые сообщения, то ластриды правятся для _всех_ пользователей. В этом плане sqpack работает корректно.

    Чтобы починить голдед, нужно также править ластриды для всех пользователей при удалении. Это немного другой интерфейс получится, а не то, что сейчас close() вызывает у базы метод save_lastread() для текущего просто пользователя.
    Фикс возможен, но оне не в две строчки просто.

    Best Regards, Nil
    --- GoldED+/LNX 1.1.5-b20250409
    * Origin: Gemini can make mistakes, so double-check it (2:5015/46)
  • From Stas Mishchenkov@2:460/5858 to Nil A on Sat Feb 21 14:24:50 2026
    Hi Nil!

    20 Feb 26 10:55, Nil A -> Stas Mishchenkov:

    А, вот, обнаружил я проблему, которую не знаю, как решать пока. Если
    в
    OPUS Msg Base дед удаляет сообщение, то он не правит ластриды. Если
    ластрид _другого_ пользователя указывает на удалённое сообщение с
    большим номером, чем существующие, то так и останется. Если новые
    сообщения будут тоже с меньшим номером, то они для другого
    пользователя будут считаться прочитанными, а это не правильно и
    чревато. а сколько я понимаю, починить это не трудно.

    Как в OPUS Msg хранятся ластриды, я спек на найду сходу.
    Сделал msg область в голдеде, он создал в каталоге файл lastread 2 байта, видимо в Little-Endian номер сообщения. А если будет много пользователей, то это как Squish ID, типа индекс в этом файле?

    Да. два байта на юзера. омер сообщения, АКА имя файла без расширения. Причём, если у тебя два юзера, userno 0 и userno 127, то файл будет 256 байт, байты несуществующих номеров пользователей забиты нулями.

    Have nice nights.
    Stas Mishchenkov.

    --- Ты можешь не смотреть телевизор,но будешь иметь дело с теми,кто его смотрит
    * Origin: Lame Users Breeding. Simferopol, Crimea. (2:460/5858)
  • From Stas Mishchenkov@2:460/5858 to Nil A on Sat Feb 21 19:27:18 2026
    Hi Nil!

    21 Feb 26 08:27, Nil A -> Stas Mishchenkov:

    А, вот, обнаружил я проблему, которую не знаю, как решать пока. Если
    в
    OPUS Msg Base дед удаляет сообщение, то он не правит ластриды. Если
    ластрид _другого_ пользователя указывает на удалённое сообщение с
    большим номером, чем существующие, то так и останется. Если новые
    сообщения будут тоже с меньшим номером, то они для другого
    пользователя будут считаться прочитанными, а это не правильно и
    чревато. а сколько я понимаю, починить это не трудно.

    Посмотрел. Обновление lastread происходит при _выходе_ из арии,

    у, хоть так...

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

    А это совсем плохо.

    Такой подход работает для Squish и JAM в режиме "soft" удаления.

    о для других-то пользователей они тоже удалены.

    В OPUS/Msg сообщения удаляются всегда по-сути "hard",
    причём могут переиспользоваться старые номера - тут и возникает
    описанная тобой проблема.

    Вот-вот. В идеале, конечно, сразу бы обновлять все ластриды, но хотя бы при выходе из области...

    Я посмотрел код Хаски утилиты sqpack, и при перепаковки баз, если есть удалённые сообщения, то ластриды правятся для _всех_ пользователей. В этом плане sqpack работает корректно.

    https://brorabbit.g0x.ru/files/perl/maintjam.pl и https://brorabbit.g0x.ru/files/perl/maintmsg.pl тоже именно так делает.

    Чтобы починить голдед, нужно также править ластриды для всех
    пользователей при удалении. Это немного другой интерфейс получится, а
    не то, что сейчас close() вызывает у базы метод save_lastread()

    Вот его и нужно править. Я правильно понял? А желательно и вызывать при удалении msg.

    для текущего просто пользователя. Фикс возможен, но оне не в две
    строчки просто.

    Подозреваю, что не в две.

    ужно что-то такое:

    for ( $i = 0; $i < $users; $i++ ) {
    $lastreads[$i] = 0 if !defined $lastreads[$i];
    if ( $lastreads[$i] > 0 ) {
    while( !-e catfile($msgDir, "$lastreads[$i]\.msg") {
    $lastreads[$i] --;
    last if $lastreads[$i] == 0;
    }
    }
    }

    Соответственно, привходе в арию читать все ластриды, а не только одного пользователя.

    PS: Я знаю, что правильно - ластрэд. ;)

    Have nice nights.
    Stas Mishchenkov.

    --- Общественное мнение - это мнение тех, кого не спрашивают.
    * Origin: Lame Users Breeding. Simferopol, Crimea. (2:460/5858)
  • From Vitaliy Aksyonov@1:104/117 to Nil A on Sat Feb 21 11:33:30 2026
    Привет, Nil!

    20 Feb 26 10:08, ты писал(а) Konstantin Simonov:

    Hello, Konstantin!

    Thursday February 19 2026 22:46, from Konstantin Simonov -> Oleg
    Artemjev:

    етмейлом конечно стоит помочь, но здесь не нетмейл и нет смысла
    тратить время на расшифровку БОПИ.

    бОПЯ починена в Голдеде. Суть проблема уже изложил в предыдущем
    письме. Заняло несколько минут, ИИ починил по вот такому промту, и ещё
    мне минут 10 чтобы потом разобраться и сделать код-ревью.

    [...skipped...]

    Залил патч в гит.

    Best regards,
    Vitaliy Aksyonov.

    ... Я за тебя свою работу делать не буду!
    --- GoldED+/LNX 1.1.5-b20240309
    * Origin: Aurora, Colorado (1:104/117)
  • From Nil A@2:5015/46 to Vitaliy Aksyonov on Sat Feb 21 23:34:30 2026
    Hello, Vitaliy!

    Saturday February 21 2026 11:33, from Vitaliy Aksyonov -> Nil A:

    бОПЯ починена в Голдеде.
    Залил патч в гит.

    Спасибо!

    P.S. Оставайся мальчик с нами, будешь нашим королём (c)
    т.е. не пропадай то совсем так на долго

    Best Regards, Nil
    --- GoldED+/LNX 1.1.5-b20250409
    * Origin: Gemini can make mistakes, so double-check it (2:5015/46)
  • From Max Vasilyev@2:5057/77 to Vitaliy Aksyonov on Mon Feb 23 11:25:07 2026
    Hello Vitaliy!

    21 Feb 26 11:33, you wrote to Nil A:

    Залил патч в гит.
    а reldate и __SRCDATE__ поправить в golded.spec и srcdate.h?

    WBR, Max.
    --- скучаю по FleetStreet'у :-(((
    * Origin: Personal Reality (2:5057/77)
  • From Nil A@2:5015/46 to Stas Mishchenkov on Fri Feb 27 04:52:06 2026
    Hello, Stas!

    Tuesday February 17 2026 23:07, from Stas Mishchenkov -> Nil A:

    А, вот, обнаружил я проблему, которую не знаю, как решать пока. Если в OPUS Msg Base дед удаляет сообщение, то он не правит ластриды. Если ластрид _другого_ пользователя указывает на удалённое сообщение с
    большим номером, чем существующие, то так и останется. Если новые сообщения будут тоже с меньшим номером, то они для другого
    пользователя будут считаться прочитанными, а это не правильно и
    чревато. а сколько я понимаю, починить это не трудно.

    ПочиИЛ. Теперь при удалении сообщения в OPUS/MSG, правятся Lastread для всех пользователей, плюс если по ошибке lastread указывает за максимально доступным и не удалённым сообщением, то тоже чинится.
    Я у себя всё аккуратно проверил. Проверяй, и я попрошу тогда Виталия залить на гитхаб.


    From 6f2be3dff66bc57b09c407ec1bd7fb33f6d0b70a Mon Sep 17 00:00:00 2001
    From: Nil Alexandrov <nil.alexandrov@gmail.com>
    Date: Thu, 26 Feb 2026 20:47:37 -0500
    Subject: [PATCH] Fix OPUS/MSG: update all users' lastread after deleting *.MSG

    OPUS bases hard-delete message files, leaving other users' lastread
    pointers pointing at removed message numbers. This could cause newer lower-numbered messages to be treated as already read and missed.

    After deleting a *.MSG, scan the lastread file and adjust any entries
    that point to the deleted message (or exceed the current max) to the
    nearest valid existing message number.
    -+-
    goldlib/gmb3/gmofido3.cpp | 1 +
    goldlib/gmb3/gmofido4.cpp | 82 ++++++++++++++++++++++++++++++++++++++-
    2 files changed, 82 insertions(+), 1 deletion(-)

    diff --git a/goldlib/gmb3/gmofido3.cpp b/goldlib/gmb3/gmofido3.cpp
    index 7d13a17..fd3207b 100644
    --- a/goldlib/gmb3/gmofido3.cpp
    +++ b/goldlib/gmb3/gmofido3.cpp
    @@ -36,6 +36,7 @@

    int FidoArea::load_message(int __mode, gmsg* __msg, FidoHdr& __hdr)
    {
    + GFTRK("FidoLoadMessage");

    // Build message filename
    Path _msgfile;
    diff --git a/goldlib/gmb3/gmofido4.cpp b/goldlib/gmb3/gmofido4.cpp
    index 6c04e41..8c4a72b 100644
    --- a/goldlib/gmb3/gmofido4.cpp
    +++ b/goldlib/gmb3/gmofido4.cpp
    @@ -62,6 +62,7 @@ void FidoArea::unlock()

    void FidoArea::save_message(int __mode, gmsg* __msg, FidoHdr& __hdr)
    {
    + GFTRK("FidoSaveMessage");

    // Build message filename
    Path _msgfile;
    @@ -264,9 +265,88 @@ void FidoArea::del_msg(gmsg* __msg)

    FidoHdr _hdr;
    save_message(GMSG_HDR | GMSG_DELETE, __msg, _hdr);
    -}

    + // Determine the highest remaining message number and the highest
    + // remaining message number that is lower than the deleted message
    + uint32_t _deleted_msgno = __msg->msgno;
    + word _max_msgno = 0;
    + word _prev_msgno = 0;
    + uint _count = Msgn->Count();
    +
    + if (_count > 0) {
    + _max_msgno = (word)Msgn->at(_count - 1);
    + if (_max_msgno == _deleted_msgno) {
    + _max_msgno = (word)((_count > 1) ? Msgn->at(_count - 2) : 0);
    + }
    +
    + // Binary search for the largest message number less than _deleted_msgno
    + int left = 0, right = _count - 1;
    + while (left <= right) {
    + int mid = left + (right - left) / 2;
    + uint32_t val = Msgn->at(mid);
    + if (val < _deleted_msgno) {
    + _prev_msgno = (word)val;
    + left = mid + 1;
    + } else {
    + right = mid - 1;
    + }
    + }
    + }
    +
    + // Update lastread pointers for all users in the lastread file.
    + int _fh = ::sopen(AddPath(real_path(), wide->fidolastread), O_RDWR|O_BINARY, WideSharemode, S_STDRW);
    + if(_fh != -1)
    + {
    + // Get the file size to determine how many user entries exist
    + long _filesize = filelength(_fh);
    + long _numusers = _filesize / (long)sizeof(word);
    +
    + if(_numusers > 0)
    + {
    + word* _lr_array = new word[_numusers];

    + // Read the entire lastread file into memory
    + lseekset(_fh, 0);
    + if(read(_fh, _lr_array, _numusers * sizeof(word)) == (int)(_numusers * sizeof(word)))
    + {
    + bool _changed = false;
    +
    + // Scan through all user entries
    + for(long _u = 0; _u < _numusers; _u++)
    + {
    + // If this user's lastread points to the deleted message, + // update it to the next lower existing message number.
    + if(_lr_array[_u] == (word)_deleted_msgno)
    + {
    + _lr_array[_u] = _prev_msgno;
    + _changed = true;
    + }
    +
    + // If a user's lastread pointer is higher than the maximum + // available message (e.g., due to corruption), set it to max.
    + if(_lr_array[_u] > _max_msgno)
    + {
    + _lr_array[_u] = _max_msgno;
    + _changed = true;
    + }
    + }
    +
    + // If any pointers were updated, write the array back to disk + if(_changed)
    + {
    + lseekset(_fh, 0);
    + write(_fh, _lr_array, _numusers * sizeof(word));
    + }
    + }
    +
    + delete[] _lr_array;
    + }
    +
    + ::close(_fh);
    + }
    +
    + GFTRK(0);
    +}
    // ------------------------------------------------------------------

    void FidoArea::new_msgno(gmsg* __msg)
    --
    2.53.0

    === Конец патчика.

    Best Regards, Nil
    --- GoldED+/LNX 1.1.5-b20250409
    * Origin: Gemini can make mistakes, so double-check it (2:5015/46)
  • From Semen Panevin@2:5025/121 to Nil A on Fri Feb 27 05:42:56 2026
    Доброго здоровьица тебе, Nil!

    Friday February 27 2026 04:52, Nil A писал Stas Mishchenkov:

    себя всё аккуратно проверил. Проверяй, и я попрошу тогда Виталия
    залить на гитхаб.

    Процитирую Макса Васильева пожалуй

    Залил патч в гит.
    reldate и __SRCDATE__ поправить в golded.spec и srcdate.h?

    С наилучшими пожеланиями, Семён.

    ... Учиться, учиться и учиться! (с) Ленин
    --- GoldED+/LNX 1.1.5-b20250409 (Linux 6.18.12-gentoo iF6M10)
    * Origin: IceLAN (2:5025/121)
  • From Nil A@2:5015/46 to Semen Panevin on Fri Feb 27 06:52:18 2026
    Hello, Semen!

    Friday February 27 2026 05:42, from Semen Panevin -> Nil A:

    Процитирую Макса Васильева пожалуй
    Залил патч в гит.
    а reldate и __SRCDATE__ поправить в golded.spec и srcdate.h?

    Хоспаде, там надо как-то средствами git это сделать, чтобы не руками каждый раз чтоли.
    Ладно, держите.

    From 2c38002e02d15412866d9d88fc4fd2ab4bf54ea0 Mon Sep 17 00:00:00 2001
    From: Nil Alexandrov <nil.alexandrov@gmail.com>
    Date: Thu, 26 Feb 2026 22:51:32 -0500
    Subject: [PATCH 2/2] change srcdate and spec

    -+-
    golded.spec | 2 +-
    srcdate.h | 2 +-
    2 files changed, 2 insertions(+), 2 deletions(-)

    diff --git a/golded.spec b/golded.spec
    index 9c904c9..fb8807c 100644
    --- a/golded.spec
    +++ b/golded.spec
    @@ -1,4 +1,4 @@
    -%define reldate 20250409
    +%define reldate 20260226
    %define reltype C
    # may be one of: C (current), R (release), S (stable)

    diff --git a/srcdate.h b/srcdate.h
    index 44ef372..ff63fa6 100644
    --- a/srcdate.h
    +++ b/srcdate.h
    @@ -1,3 +1,3 @@
    #ifndef __SRCDATE__
    -#define __SRCDATE__ "20250409"
    +#define __SRCDATE__ "20260226"
    #endif
    --
    2.53.0

    == конец патчика

    Best Regards, Nil
    --- GoldED+/LNX 1.1.5-b20250409
    * Origin: Gemini can make mistakes, so double-check it (2:5015/46)
  • From Nil A@2:5015/46 to Max Vasilyev on Fri Feb 27 07:19:20 2026
    Hello, Max!

    Monday February 23 2026 11:25, from Max Vasilyev -> Vitaliy Aksyonov:

    Залил патч в гит.
    а reldate и __SRCDATE__ поправить в golded.spec и srcdate.h?

    у это же не задача разработчика патчика, а Release Engineer'а. С релизами, кстати, вообще всё плохо, потому что мы застряли на 1.1.5 просто.

    Я не знаю чем в Windows, DOS и OS/2 собирают, но для CMake и Makefile можно придумать что-то типа.

    === Для корневого CMakeLists.txt ===
    execute_process(
    COMMAND git log -1 --format=%cd --date=format:%Y%m%d
    WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}
    OUTPUT_VARIABLE GIT_DATE
    OUTPUT_STRIP_TRAILING_WHITESPACE
    )
    file(WRITE ${CMAKE_BINARY_DIR}/srcdate.h "#ifndef __SRCDATE__\n#define __SRCDATE__ \"${GIT_DATE}\"\n#endif\n")
    include_directories(${CMAKE_BINARY_DIR})

    === Для Makefile ===
    srcdate.h:
    echo "#ifndef __SRCDATE__" > srcdate.h
    echo "#define __SRCDATE__ \"`git log -1 --format=%cd --date=format:%Y%m%d`\"" >> srcdate.h
    echo "#endif" >> srcdate.h

    === Для rpmbuild запускать ===
    rpmbuild -D "reldate $(git log -1 --format=%cd --date=format:%Y%m%d)"

    Или сделать эти два файла шаблонами srcdate.h.in и golded.spec.in

    ====srcdate.h.in===
    #ifndef __SRCDATE__
    #define __SRCDATE__ "@SRCDATE@"
    #endif

    ===golded.spec.in===
    %define reldate @SRCDATE@

    И генерировать их тоже
    ===Cmake===
    configure_file(${CMAKE_SOURCE_DIR}/srcdate.h.in ${CMAKE_BINARY_DIR}/srcdate.h @ONLY)
    configure_file(${CMAKE_SOURCE_DIR}/golded.spec.in ${CMAKE_BINARY_DIR}/golded.spec @ONLY)

    ===Makefile====
    srcdate.h: srcdate.h.in SRCDATE
    sed 's/@SRCDATE@/$(SRCDATE)/g' $< > $@

    golded.spec: golded.spec.in SRCDATE
    sed 's/@SRCDATE@/$(SRCDATE)/g' $< > $@

    Best Regards, Nil
    --- GoldED+/LNX 1.1.5-b20250409
    * Origin: Gemini can make mistakes, so double-check it (2:5015/46)
  • From Semen Panevin@2:5025/121 to Nil A on Fri Feb 27 21:51:22 2026
    Доброго здоровьица тебе, Nil!

    Friday February 27 2026 06:52, Nil A писал Semen Panevin:

    а reldate и __SRCDATE__ поправить в golded.spec и srcdate.h?

    Хоспаде, там надо как-то средствами git это сделать, чтобы не руками каждый раз чтоли. Ладно, держите.
    Это раньше было сделано средствами CVS. Средствами git это как-то сильно невозможнее...

    апрашивается некая смена процесса, но видимо всем лень и некогда.

    С наилучшими пожеланиями, Семён.

    ... Жизнь принуждает человека ко многим добровольным действиям... (c)...
    --- GoldED+/LNX 1.1.5-b20250409 (Linux 6.18.12-gentoo iF6M10)
    * Origin: IceLAN (2:5025/121)
  • From Nil A@2:5015/46 to Semen Panevin on Fri Feb 27 23:08:32 2026
    Hello, Semen!

    Friday February 27 2026 21:51, from Semen Panevin -> Nil A:

    а reldate и __SRCDATE__ поправить в golded.spec и srcdate.h?

    Хоспаде, там надо как-то средствами git это сделать, чтобы не
    руками каждый раз чтоли. Ладно, держите.

    Это раньше было сделано средствами CVS. Средствами git это как-то
    сильно невозможнее...
    апрашивается некая смена процесса, но видимо всем лень и некогда.

    Классика вообще. По работе столько CVS реп переведено в git.
    В .gitattributes надо задать ident атрибуты, например,
    ===
    *.c ident
    *.h ident
    ===
    тогда, при git checkout, clone, pull, merge, .. он будет $Id$ обновлять, при этом при commit, он будет снова вычищать.
    Кстати, можно написать через "*.h filter=expand-id" какой-нибудь в .gitattributes, чтобы как-то по-особенному эту строчку формировать.

    Best Regards, Nil
    --- GoldED+/LNX 1.1.5-b20250409
    * Origin: Gemini can make mistakes, so double-check it (2:5015/46)
  • From Semen Panevin@2:5025/121 to Nil A on Sat Feb 28 10:35:56 2026
    Доброго здоровьица тебе, Nil!

    Friday February 27 2026 23:08, Nil A писал Semen Panevin:

    а reldate и __SRCDATE__ поправить в golded.spec и srcdate.h?

    Хоспаде, там надо как-то средствами git это сделать, чтобы не
    руками каждый раз чтоли. Ладно, держите.

    Это раньше было сделано средствами CVS. Средствами git это как-то
    сильно невозможнее...
    апрашивается некая смена процесса, но видимо всем лень и
    некогда.

    Классика вообще. По работе столько CVS реп переведено в git.
    В .gitattributes надо задать ident атрибуты, например,
    ===
    *.c ident
    *.h ident
    ===
    тогда, при git checkout, clone, pull, merge, .. он будет $Id$
    обновлять, при этом при commit, он будет снова вычищать. Кстати, можно написать через "*.h filter=expand-id" какой-нибудь в .gitattributes,
    чтобы как-то по-особенному эту строчку формировать.

    И с какой стороны там date? :)

    Git может далеко не всё, что могут svn и даже cvs...

    С наилучшими пожеланиями, Семён.

    ... Жизнь принуждает человека ко многим добровольным действиям... (c)...
    --- GoldED+/LNX 1.1.5-b20250409 (Linux 6.18.12-gentoo iF6M10)
    * Origin: IceLAN (2:5025/121)