Добро пожаловать, Гость. Пожалуйста авторизуйтесь здесь.
FGHIGate на GaNJa NeTWoRK ST@Ti0N - Просмотр сообщения в эхоконференции UTF-8
Введите FGHI ссылку:


Присутствуют сообщения из эхоконференции UTF-8 с датами от 19 Apr 14 00:41:48 до 01 Apr 24 00:03:00, всего сообщений: 1367
Ответить на сообщение К списку сообщений Предыдущее сообщение Следующее сообщение
= Сообщение: 725 из 1367 ============================================= UTF-8 =
От   : mark lewis                       1:3634/12.73       04 Apr 19 15:59:04
Кому : Richard Menedetter                                  04 Apr 19 15:59:04
Тема : goated
FGHI : area://UTF-8?msgid=1:3634/12.73+5ca66762
На   : area://UTF-8?msgid=2:310/31+5ca64ade
= Кодировка сообщения определена как: CP437 ==================================
Ответ: area://UTF-8?msgid=2:310/31+5ca675ca
==============================================================================
 On 2019 Apr 04 20:19:54, you wrote to me:

RM>>> I have found that messages that I read in GoatEd are shown as
RM>>> unread in Golded.
ml>> JAM message base format or something else? it could be that the two
ml>> are using different lastread pointer records...

RM> Yes, JAM.

ok...

RM> It is a single user system.

ok... that makes it easier...

RM> I have not configured anything special in golded or goated about using
RM> another lastread pointer.

you don't have to... generally those options are provided so you can force
separate tools to use the same LR pointer record...

using a hex editor, look at the JLR file for the area in question... the jlr
file should be a multiple of 16 because there are 16 bytes allocated to the
lastread records for each user...

looking internally with a hex editor, you may see two sets of identical
fields... the first field (four bytes) should be the CRC32 of the lowercase
user name... the second field (four bytes) should be the user number... in some
 JAM capable software, they use the same value in both fields...

the other two fields are the lastread and highread fields... they may be the
same if the user's lastread is the highest they have read in the area otherwise
 they should be different with the second one being a higher decimal value...
some software keeps them both the same which rather negates the feature of
having a highread value...

anyway, just thought i'd provide that info in case it may be helpful... if one
package uses a different record or uses the lastread and highread values
differently, you may see some oddities when switching between the two
packages...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it
wrong...
... Hydrogen bombs are great party gags.
---
* Origin:  (1:3634/12.73)

К главной странице гейта
Powered by NoSFeRaTU`s FGHIGate
Открытие страницы: 0.011031 секунды