John Summerfied writes:
>Edmund R. MacKenty wrote:
>> James Melin writes:
>>
>>>Actually, if you have the disk as ext3, you get gazillions of errors when
>>>it is R/O because the system that is mounting the disk R/O tries to use the
>>>journal too but it cant open it R/W.
>>
>>
>> This is only true if you mounted the device read-write in Linux. Any time
>> you are using a read-only device, you should be sure to use the "ro" mount
>> option, or you'll waste a lot of cycles.
>>
>> 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.
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.
>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.
>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.
>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 don't believe it.
UNIX-land is a strange place, fully of wierd and mystical things. I'm sure
someone knows how this particular bit of strangeness came to be, but I can
only speculate: Way back at Bell Labs, someone must have thought, "How
should I save this meta-data about if mail has been delivered since the
last time the mailbox was read? I could write it to a separate file, or
prepend a header, but that would be wasteful. I know! I'll put it in this
last-access timestamp in the i-node. No one really uses that field
anyway..." :-) And thus a hack was preserved for us to talk about years
later.
These days, many systems use the "maildir" approach, in which each user is
given a directory with each mail message in its own file. Of course there
is a file of meta-data which last-read-time information is stored in. But
the default for most UN*X systems is still the old UNIX mailbox format.
- MacK.
-----
Edmund R. MacKenty
Software Architect
Rocket Software, Inc.
Newton, MA USA
----------------------------------------------------------------------
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
