Hello

I'm sure that you will have now found out that this flag is not saved:

grep -r nsMsgMessageFlags::New * mailnews/db/msgdb/src/nsMsgHdr.cpp: m_flags &= ~nsMsgMessageFlags::New; // don't get new flag from MDB mailnews/db/msgdb/src/nsMsgHdr.cpp: // don't write out nsMsgMessageFlags::New to MDB.

@gp I'm not sure what you are trying to tell me... A detail I should probably have mentioned : I use a POP3 account.

Grepping my Inbox file with nsMsgMessageFlag yields no result (nor with nsMsg, for that matter).

In other words : grep nsMsg /path/to/Inbox returns nothing.

What I am saying is that you are relying on an unofficial documentation, and you are concluding that Thunderbird is not conforming to this 'documentation', while in reality there was never any contract that the mail files were including the information you need. In other words, it's probably not possible to do what you want by reading the mail files. I say 'probably' because I did not consider the possibility that other flags may help you to get this information. And there is no reason that the mail files include names used in the source code. The code is compiled and then the object result manages the mail files. No relation at all.

>>it's probably not possible to do what you want by reading the mail files

It is possible, kind of. Right now I rely on the index file's atime (access time) attribute, but I was wondering if there was a better way to do that.

What I do now :

I noticed that whenever I access the inbox, Inbox.msf'a atime is updated, but not Inbox's atime (unless of course I alter the inbox)

So, basically :

• If the last email in the inbox is unread (e.g., if it has "X-Mozilla-Status: 0000") AND if Inbox and Inbox.msf's atime are identical (or close, a few seconds of difference), THEN it means I have NEW messages in Inbox

• If the last email in Inbox file is already read, (X-Mozilla-Status: 0001), then obviously I have NO NEW messages

• And if the last email in Inbox file is unread, BUT Inbox.msf's atime is later than Inbox's atime, THEN it means that I opened the inbox since the arrival of the last email, so I have NO NEW messages, although the last one is still unread.

The last condition is not 100% accurate though, because on some rare occasions the Inbox.msf's atime is updated even though I didn't open the inbox. I guess it's due to some behind-the-scene housekeeping of TB. But it's not frequent, I noticed it once in 2 days, so it's still a fairly reliable way to do it, although not perfect.

> I did not consider the possibility that other flags may help you to get this information

No, it appears that's not the case. I just did a diff between two versions of the inbox file, with and without new messages, there are no differences. So TB probably stores this info in its own code, not in the mail files. Only the read/unread status is stored in the mail files.

>>it's probably not possible to do what you want by reading the mail files It is possible, kind of. Right now I rely on the index file's atime

Well, atime is not known to be universally supported on all Linux computers so I'm not sure that it's a good choice to base a software plugin on it.

If someone else stumbles upon this post and has the same need :

No need to reinvent the wheel, but sometimes existing wheels are not that easy to find. Finally I found what I was looking for : https://github.com/Ximi1970/systray-x

It comes with a TB extension, which allows it to get the new messages in real time from within TB

Works well on my laptop (Debian 11 / Gnome 3.38)

it's probably not possible to do what you want by reading the mail files

I agree, and I am quite convinced now that the "new" state of a message is internal to TB's process. What makes me say that is that, if you have new messages and you restart TB, there are no more new messages.

Which explains why the only tools that I know of and that are able to reliably display the new messages count rely on a TB extension.