Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!cs.uoregon.edu!ogicse!intelhf!ichips!iwarp.intel.com!gargoyle!chinet!les
From: les@chinet.chi.il.us (Leslie Mikesell)
Newsgroups: comp.mail.misc
Subject: Re: Will ELM ever use lockf()?
Message-ID: <1991Apr15.195829.9654@chinet.chi.il.us>
Date: 15 Apr 91 19:58:29 GMT
References: <1991Apr11.024849.29924@Veritas.COM> <1991Apr11.181909.13503@chinet.chi.il.us> <1991Apr15.085531.14547@Veritas.COM>
Organization: Chinet - Chicago Public Access UNIX
Lines: 60

In article <1991Apr15.085531.14547@Veritas.COM> tron@Veritas.COM (Ronald S. Karr) writes:

>>Personally, I think the "right" solution is to deliver new mail into
>>individual files per message with a naming convention so incomplete
>>temporary files could be ignored by the mail reader.

>Every modern OS has file locking capabilities which are entirely
>sufficient for mail.  They are just unused for mail in UNIX OS's,
>except in 4.3BSD and its derivatives.  Also, I believe that NFS lacks
>a true atomic exclusive create, so NFS (but not RFS) has a window
>of vulnerability that will break many (though not all) message file
>naming conventions.

Something like the time and inode number encoded into base64 should
work...  Of course you need to create the file under some other name
to get the inode number, but something based on the hostname and pid
should work for that.

>> You could require the destination directory to already exist, which
>> would allow you to detect an unmounted NFS/RFS mount point and defer
>> delivery instead of writing in a directory that will become hidden
>> when the net comes back up.

>There is no difference between directories and single files here, since
>a mailer can just as easily check for existence of a file as existence
>of a directory.  It is just a matter of coming up with the agreed upon
>conventions to accomplish this task.

Yes, I suppose you could force the UA to leave a 0 length file when the
mailbox is empty, but I was thinking of what currently happens if you
mount /usr/mail from a different machine and the other machine goes
down.  Creating /usr/mail/you succeeds anyway, but the file won't be
seen again after the network mount comes back.  Creating /usr/mail/you/tmp
would fail in a way that is easily detected.  Another side effect would
be that the mail user agent would not need any special permissions if
the directory belonged to the user.

>> You could deliver to multiple recipients on the same machine with
>> a simple link.  This would make mailing lists about as cheap as
>> a newsgroup and easier to maintain since the disk space would
>> automatically be released when the last recipient's copy is deleted.

>As with news, the relative efficiency of this solution is a function
>of the average message size, the average number of recipients and the
>overhead required for a file.  When I used mh some time ago, and stored
>all of my mail in single files, I found the overhead to be far too
>great to consider the solution viable.  You have to at least migrate
>messages into groups stored in single files; otherwise, searches become
>too slow, and the storage efficiency gets too low.

Ideally, the UA would gather up the new messages and consolidate the
ones you want to keep into a format better suited for long-term storage.
There should not be any contention for the files at this point.
For me, the most common action is to read new messages fairly frequently,
deleting most after reading and possibly printing them.  The
message-per-file model is a win when you want to delete one and leave
the rest alone.

Les Mikesell
  les@chinet.chi.il.us