Gottipati Aravind <[EMAIL PROTECTED]> wrote on Tue, 06 Jun 2000:
> I use fetchmail to get the mail and Procmail to deliver it. so I dont
> think its the second one i.e its probably not an NFS problem.
Well, if you *do* use NFS, it might be a NFS problem. If you don't use
NFS, then it can't be NFS. :-) It has nothing to do with
fetchmail/procmail being the method of getting/delivering the mail.
In case you don't know, NFS is the network file system (network mounted
drives/dirs), so if you only have a single machine you likely aren't
using it. :-)
> And also
> in some cases after I check the mail in spool folder, typing "c<space>"
> actually works. i.e it gives me the name of the next folder like "=fslc"
> or something like that, that has new mail, but in most cases it does not
> work.
Well, this indicates that at least there's nothing wrong with Mutt, it's
just a question of finding out why the file timestamps get changed.
> Also in the rare case where it does work, it does not recognise the
> other mailing list folders where there is new mail.
That just means that the timestamps are off in the other folders but not
in this one where it recognised it having new mail.
> I have xbiff, but I
> doubt that its even running when I am in console, plain text terminals.
> In anycase, I dont think it would check mail in folders other than spool
> without me explicitly setting it up to do so. (which I have not)
Yes, it wouldn't, that's likely not the problem.
If you want to view the file access time, you can see it with
ls -l --time=access folderfile
(with GNU ls anyway, other versions of ls likely have some other option
for it...)
[re-arranged text]
> It would be great if you also added what the most common remedies to
> this were (based on what you read, that is) :-) and what were the most
> probable reasons for this to happen.. ie. what are the programs that you
> think can check mail before mutt does and change that timestamp.
> > 1) the folder has been opened before with Mutt or another email program
Well, in this case the folder has been viewed, so even if it has unread
("new") messages in it, it isn't considered to contain new email anymore
because the user (you) have already seen it.
I suppose email programs could be changed (patched) to re-set the access
time to earlier than the modification time if the folder still contains
new emails when exiting. But this isn't default in any MUA, I think.
(Not sure, I could easily be wrong in this, I'm not even sure what Mutt
does...)
> > 2) problems with timestamps for files served over NFS (but if you're
> > using NFS I strongly recommend Maildir format anyway)
mbox and NFS don't play along well, I'd strongly recommend switching to
Maildir.
Actually, what I neglected to mention in the previous email is that you
might consider switching to Maildir format anyway. In Maildir, new
messages are stored in a special directory (part of the folder internal
structure), so the folder's "new messages" state is not subject to the
flakyness inherent to the mbox-format method of playing with the
timestamps. The latest version of procmail (3.14) even has built-in
support for Maildirs, which was a problem for earlier versions. Mutt
works fine with Maildirs, however other email-programs may not support
it. But if you're happy with using only Mutt for your email handling,
then you should be fine. Maildir format may have slightly worse
performance in some circumstances (than mbox), but it only becomes
apparent with large folders (say, 1000 to 10000 messages, or more).
> > 3) new mail notifiers which scan the folder and don't reset the last
> > accessed timestamp
The solution here is either not to run the notifier or fix it so that it
properly resets the access timestamp after scanning the folder.
Which programs can do this... Well, any new-mail notifier, there's a
plethora of them. Also worth noting is that some shells have a new-mail
notification feature, that might be the culprit.
> > 4) backup programs which read the folder files
See above. You may not want to do backups of incoming mail folders
anyway, as the files soon become outdated.
Hope this helps,
Mikko
--
// Mikko Hänninen, aka. Wizzu // [EMAIL PROTECTED] // http://www.iki.fi/wiz/
// The Corrs list maintainer // net.freak // DALnet IRC operator /
// Interests: roleplaying, Linux, the Net, fantasy & scifi, the Corrs /
"Scotty, beam us aboard." "Aye, sir. Will a 2x4 do?"
