N-flag stays put after reading

Hello mutters,

After switching from mutt-1.4.1i-11 to 1.4.2.1-1 due to an
upgrade of MacOS X and my getting mutt from fink mutt tends to
keep the N-flag on new messages that I've already read -- which
is rather annoying when I switch mailboxes (unix), then again
hit c for <change-folder> and it offers me the mailbox I just
came from as having new messages.

Is this because it's compiled without BUFFY_SIZE?

I also turned off journaling of the file system temporarily but
this didn't change the behaviour?

I wonder why the older version worked.

Ideas anyone?

TIA

c
--
Wer auf sein Elend tritt, steht höher.
_HÖLDERLIN: H Y P E R I O N_ <http://www.blacktrash.org/>

Hello Christian,

On Wednesday, December 1, 2004 at 8:43:37 AM +0100, Christian Ebert wrote:

> mutt tends to keep the N-flag on new messages that I've already read

You mean «*on new mailboxes*»: Your filesystem has correct access
times?


Bye! Alain.
--
Mutt muttrc tip to send mails in best adapted first necessary and sufficient
charset (version for East Europe Latin-2/CP-852/CP-1250 terminal users):
set send_charset="us-ascii:iso-8859-1:iso-8859-15:windows-1252:iso-8859-2:windows-1250:utf-8"

Hello Alain,

* Alain Bench on Wed, Dec 01, 2004:
> On Wednesday, December 1, 2004 at 8:43:37 AM +0100, Christian Ebert wrote:
>> mutt tends to keep the N-flag on new messages that I've already read
>
> You mean «*on new mailboxes*»: Your filesystem has correct access
> times?

$ls -ul shows correct times but -- after some testing -- access
time is not always updated. But when and if it's updated it
updates to the correct time. Just now it took almost 5 minutes
for a mailbox to update; and I can't tell what caused the update.

A friend of mine has the same behaviour on his machine after the
same updates of MacOS, fink and mutt respectively.

File system on MacOS 10.2 was HFS+ IIRC, whereas now it's called
"MacOS (Journaled)" -- don't know whether this is still basicly
HFS+.

Sorry if this is the wrong list but on fink-users nobody answered
when I brought up the problem.

c
--
$ man woman
No manual entry for woman

* Christian Ebert <blacktrash@gmx.net> [2004-12-01]:
> Sorry if this is the wrong list but on fink-users
> nobody answered when I brought up the problem.

how about upgrading your mutt and slrn
and then posting your problems to one
of the mailing lists set up for them?!

Sven

On 2004-12-01, Christian Ebert <blacktrash@gmx.net> wrote:
> After switching from mutt-1.4.1i-11 to 1.4.2.1-1 due to an
> upgrade of MacOS X and my getting mutt from fink mutt tends to
> keep the N-flag on new messages that I've already read

I'm running mutt 1.4.2.1i in osx 10.3.6 and I'm not seeing this. I gave
up on fink some time ago; I now compile 3rd-party packages by hand and
install them into /usr/local. In the case of mutt the configure options
I used were --with-slang --with-ssl --enable-pop --enable-imap. New
mail comes in from a pop account (usually via background fetchmail,
sometimes with 'G' in mutt). Saved mail is mostly on the imap server,
though I also sometimes have local mail files around for awhile.


> Is this because it's compiled without BUFFY_SIZE?

I didn't enable this option when I built mutt.


> I also turned off journaling of the file system temporarily but
> this didn't change the behaviour?

Keep the journaling on; it has nothing to do with this. Journaling is
completely transparent to file access. It's there mostly to help deal
with corruption that can occur when a volume isn't unmounted properly
(eg if the system crashes).

On 1 Dec 2004 17:30:33 GMT, Sven Guckes wrote:
> * Christian Ebert <blacktrash@gmx.net> [2004-12-01]:
>> Sorry if this is the wrong list but on fink-users
>> nobody answered when I brought up the problem.
>
> how about upgrading your mutt and slrn
> and then posting your problems to one
> of the mailing lists set up for them?!

The problem remains with mutt-1.5.6.
I've reported it using flea.

--

Gruss Olaf

* Olaf Foellinger <ergo@merlin.in-berlin.de> [2004-12-01]:
> On 1 Dec 2004 17:30:33 GMT, Sven Guckes wrote:
>> * Christian Ebert <blacktrash@gmx.net> [2004-12-01]:
>>> Sorry if this is the wrong list but on fink-users
>>> nobody answered when I brought up the problem.
>>
>> how about upgrading your mutt and slrn
>> and then posting your problems to one
>> of the mailing lists set up for them?!
>
> The problem remains with mutt-1.5.6.
> I've reported it using flea.

which report number is this then?
the web interface shows only reports until #1896
http://bugs.guug.de/db/si/pendingnormal.html

oh, my... there are 26 "grave bugs"
with an average of 728 days of age:

#423:1237 #714:1039 #0792:983 #0816:966 #0841:948
#0987:867 #1001:861 #1067:832 #1073:827 #1077:825
#1111:810 #1124:804 #1161:776 #1203:745 #1265:696
#1272:691 #1304:667 #1345:620 #1346:620 #1347:620
#1358:591 #1376:575 #1382:573 #1399:553 #1709:198
#1895:7

even when you kill the dix oldest bugs right away
the average just goes down to 644 days. and if
the latest grave bug had not been reported a
week ago then that avarage was 678 days. *sigh*

Sven

* Sven Guckes on Wed, Dec 01, 2004:
> how about upgrading your mutt and slrn

Or downgrade to mutt-1.4.1i as that version worked?

Judging by Olaf's message the problem persists in the current
version.

c
--
All of old. Nothing else ever. Ever tried. Ever failed.
No matter. Try again. Fail again. Fail better.
~ Samuel Beckett, Worstward Ho

* respower on Wed, Dec 01, 2004:
> On 2004-12-01, Christian Ebert <blacktrash@gmx.net> wrote:
>> After switching from mutt-1.4.1i-11 to 1.4.2.1-1 due to an
>> upgrade of MacOS X and my getting mutt from fink mutt tends to
>> keep the N-flag on new messages that I've already read
>
> I'm running mutt 1.4.2.1i in osx 10.3.6 and I'm not seeing this. I gave
> up on fink some time ago;

Usually I have no problems with the fink packages.

> I now compile 3rd-party packages by hand and
> install them into /usr/local.

Up to now I only do this with tetex-beta because I really need
the more recent features.

> In the case of mutt the configure options
> I used were --with-slang --with-ssl --enable-pop --enable-imap. New
> mail comes in from a pop account (usually via background fetchmail,
> sometimes with 'G' in mutt). Saved mail is mostly on the imap server,
> though I also sometimes have local mail files around for awhile.

Just tested it on my imap-server: no problem with the mailboxes
there! But I prefer to read my mail locally after getting it via
fetchmail.

>> Is this because it's compiled without BUFFY_SIZE?
>
> I didn't enable this option when I built mutt.

Was just something I stumbled over when I googled for the issue.

>> I also turned off journaling of the file system temporarily but
>> this didn't change the behaviour?
>
> Keep the journaling on; it has nothing to do with this. Journaling is
> completely transparent to file access.

Thanks for the clarification.

Even though concerning the issue I am having it seems less clear
because apparently I am not the only one and it also happens with
newer versions (and not from fink either).

c
--
I would prefer not to.
~ Herman Melville, Bartleby

On Wednesday, December 1, 2004 at 5:26:08 PM +0100, Christian Ebert wrote:

> access time is not always updated. But when and if it's updated it
> updates to the correct time. Just now it took almost 5 minutes for a
> mailbox to update; and I can't tell what caused the update.

Strange! And atime was updated to /now/, or to /5mn ago/? Same
behaviour with a random file outside Mutt? Size (of file) matters?
Anyway when atime < mtime the mbox is considered New, so: The N flag
disappeared after update, 5 minutes late?

I believe Olaf already tried --enable-buffy-size workaround without
success, and that's also strange, so... Sorry no other idea, besides
Googling "atime HFS+" to see if there is something known.


Bye! Alain.
--
«*if you believe a BTS week counts 7 days, I've got a bridge to sell you.*»