[Citadel Development] Re: Master: citserver coredump on Shutdown
>Pretty consistent for me. I put a check in the Berkley code to work around, >but not sure of the root cause either. Something must be getting double freed, but I can't figure out what.
[Citadel Development] Re: Merge Request: Support_IMAP_Flagged_Deleted_Draft_Recent_flags
>I just realized that a Seen message set of *:2099348686 means all messages >have been seen. Were all your messages unseen before the upgrade? I do A seen message set of *:2099348686 means all messages have been seen up to and including 2099348686. We are using what RFC 3501 (IMAP) refers to as a sequence set. If you dig through the RFC's you can read all of the BNF notation, after which you will give up and throw things at your screen. But it's pretty simple to read (maybe not to manipulate, but definitely to read) once you understand it. A sequence set is basically zero or more atoms separated by commas. Each atom can be one of five things: m (a message number) - describes exactly one message. For example: 1,2,3,10,11,12 That means exactly those six messages, and no others, existing or future. m:n (a range) - describes all messages from m to n inclusive, including any new messages that may appear inside that range in the future. For example: 1,2,3,10-12 The above example means messages 1, 2, 3, and everything from 10 to 12 inclusive. If message 11 exists it is included. If message 11 does not exist but appears later on (for example, someone moved it in to the mailbox/room from elsewhere) it is included. *:n - a range from zero to n, inclusive. You'll see this a lot in Citadel; it means "all messages up to and including n" m:* - a range from m to infinity. You'll almost never see this because it excludes any new messages that are added in the future, which isn't exactly desirable. * - all messages, any number, current or future. Again, you'll almost never see this because it excludes any new messages that are added in the future. So if someone picks through a mailbox selecting and deselecting messages, you might see something like: *:124,160,199,200-207,315 Clear as mud, right? ;) To answer your question: when I tested it I had unread messages in quite a lot of rooms. After the conversion they were all marked as read even though I had not read them.
[Citadel Development] Re: Master: citserver coredump on Shutdown
Pretty consistent for me. I put a check in the Berkley code to work around, but not sure of the root cause either.
[Citadel Development] Re: Merge Request: Support_IMAP_Flagged_Deleted_Draft_Recent_flags
Duh. Button next to Comment button. I closed.
[Citadel Development] Re: Merge Request: Support_IMAP_Flagged_Deleted_Draft_Recent_flags
>I was trying to figure out how to reject the request myself. Does not look Do you have the button "Close merge request" on the bottom of the screen?
[Citadel Development] Re: Master: citserver coredump on Shutdown
>It looks like the Berkley code is passing a NULL to a memory free routine >that does not check for NULL. Anyone else having a problem? If not, I >will look into how I build the server. It happens to me too, some of the time, and I have been busting my butt trying to figure it out.
[Citadel Development] Re: Merge Request: Support_IMAP_Flagged_Deleted_Draft_Recent_flags
I just realized that a Seen message set of *:2099348686 means all messages have been seen. Were all your messages unseen before the upgrade? I do ignore Visit records when upgrading that look bad. If they got skipped, the message set would be blank and all messages would show as unseen after the upgrade. Can you check in the log to see what the message says about the conversion. Should show a count of any records were invalid/skipped. > Wed Jul 05 2023 01:48:13 PM EDT from HarlowSolutions Subject: Re: Merge >Request: Support_IMAP_Flagged_Deleted_Draft_Recent_flags > > > >I was trying to figure out how to reject the request myself. Does not look >like you can. I Googled and others were talking about how GitLab was >lacking that option. If you can figure out how to reject or delete it, I >will not be offended unless you don't tell me how :-) Otherwise I will just >update the branch and I think the request will get updated. > >Thanks for the string. I will play with it. In my testing, the upgrade >worked on Seen, but not very extensive examples. > > > >
[Citadel Development] Master: citserver coredump on Shutdown
When I build from master now, when I shutdown citserver, it core dumps right after closing the 0d database. Since I had an issue where webcit was core dumping and was not re-creatable by anyone else, I am wondering if this is just me. It looks like the Berkley code is passing a NULL to a memory free routine that does not check for NULL. Anyone else having a problem? If not, I will look into how I build the server.
[Citadel Development] Re: Merge Request: Support_IMAP_Flagged_Deleted_Draft_Recent_flags
I was trying to figure out how to reject the request myself. Does not look like you can. I Googled and others were talking about how GitLab was lacking that option. If you can figure out how to reject or delete it, I will not be offended unless you don't tell me how :-) Otherwise I will just update the branch and I think the request will get updated. Thanks for the string. I will play with it. In my testing, the upgrade worked on Seen, but not very extensive examples.
[Citadel Development] Re: Merge Request: Support_IMAP_Flagged_Deleted_Draft_Recent_flags
Ok then, I think the proper workflow is to cancel the merge request and start a new one? I could reject it but that seems rude :) It isn't just "a seen message set" -- it was ALL of them, across all rooms, at least for me. But if you want an example, my current seen-set for this room (Citadel Development) is: *:2099348686 Are we processing the asterisk? We're using IMAP-compatible syntax, so that one means "every message up to and including 2099348686"
