Edmund R. MacKenty wrote:
John Summerfied writes:
Edmund R. MacKenty wrote:
Also, setting the "noatime" option can save a lot of work too. Linux
normally writes each i-node every time you read a file, to update the
last-access time. The "noatime" mount option turns that off, thus speeding
up reads. I use this on most filesystems because I don't care about when
files are accessed. Note that you can't use this on your mail spool,
though, because most mail clients use the difference between last-modified
and last-accessed to tell if there are new messages or not.
They do?
That cannot work where email is stored in a single file.
The original UNIX mailbox is a single file, and the local mail delivery
agent locks the file, appends the new message, then sets the last-access
time back to whatever it had been before and unlocks it. The last-modified
time is thus later than the last-access time. I know this technique,
because I've written such delivery agents.
It happens that I have mutt trained on an mbox atm.
[EMAIL PROTECTED] ~]$ stat $MAIL
File: `/var/spool/mail/summer'
Size: 106111492 Blocks: 207480 IO Block: 4096 regular file
Device: fd00h/64768d Inode: 6309524 Links: 1
Access: (0600/-rw-------) Uid: ( 1001/ summer) Gid: ( 12/ mail)
Access: 2005-11-01 16:37:28.222756163 +0800
Modify: 2005-11-01 16:31:41.206703875 +0800
Change: 2005-11-01 16:31:41.206703875 +0800
After this report I checked, and mutt shows there is new unread mail.
[EMAIL PROTECTED] ~]$ stat $MAIL
File: `/var/spool/mail/summer'
Size: 106111492 Blocks: 207480 IO Block: 4096 regular file
Device: fd00h/64768d Inode: 6309524 Links: 1
Access: (0600/-rw-------) Uid: ( 1001/ summer) Gid: ( 12/ mail)
Access: 2005-11-01 16:39:26.859859091 +0800
Modify: 2005-11-01 16:31:41.206703875 +0800
Change: 2005-11-01 16:31:41.206703875 +0800
[EMAIL PROTECTED] ~]$
and the access time is, as before, newer than the modify and change times.
This is basically nahant.
You see, the UNIX mailbox format is just a bunch of RFC-822 messages
appended to each other, with a "From " line at the beginning of each.
There's no header in which to store any meta-data about the mailbox itself,
such as when it was last written or read.
wu-imapd and pine do store metadata in the file. Here is an example:
From MAILER-DAEMON Tue Nov 1 10:49:58 2005
Date: 01 Nov 2005 10:49:58 +0800
From: Mail System Internal Data <[EMAIL PROTECTED]>
Subject: DON'T DELETE THIS MESSAGE -- FOLDER INTERNAL DATA
Message-ID: <[EMAIL PROTECTED]>
X-IMAP: 1033415628 0000000806
Status: RO
This is Pine's sent-mail folder.
It would fail if I backed up the mail spool after mail was received and
before it's read.
Only if you're doing file-level backups with something like tar(1). All
the old backups were done using dd(1), which is a device-level backup.
Later, people used dump(8), which would preserve the last-accessed time
automatically.
I'm sure a lot of folk don't use dump on Linux now: according to the man
page it only supports ext2 and ext3 while there are folk using xfs,
reiserfs and (presumably) jfs.
What happens if I write an email server that uses a database to store email?
Then you need to provide the mail client with some other way to check for
new mail. Protocols such as POP and IMAP provide ways of doing that.
the POP3 protocol provides the STAT command which provides the number of
messages and the size (in octets) of the maildrop. This would enable a
client to determine whether the maildrop has changed since it last looked.
What about if the mail's on an NT server?
Then you are probably not using UNIX mailboxes, and using IMAP to access it
and thus doing new mail notification the Windows way. If the NT server is
just providing a SMB (or NFS) share, then most mail clients that access the
file directly will not properly detect new mail.
I used to run a POP3 server on OS/2. It seemed to work perfectly fine
with the email clients I used then - ultimedia mail lite (and when I
finally tired of its numerous crashes) pmmail.
I don't believe it.
UNIX-land is a strange place, fully of wierd and mystical things. I'm sure
I know that, but this doesn't sound right. I have the RFC before me, and
I've used the protcol myself from time to time, when writing a POP3
client myself, using telnet to check mail boxes and (sometimes) to
delete email, and debugging problems with fetchmail.
I don't see anything in the protocol that requires, or even allows, a
client access to the file's times.
I'm reading rfc1939.txt which is part of the cyrus imapd distribution.
(cyrus-sasl-devel package!).
--
Cheers
John
-- spambait
[EMAIL PROTECTED] [EMAIL PROTECTED]
Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/
do not reply off-list
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
