Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news.cis.ohio-state.edu!malgudi.oar.net!news.cas.org!not-for-mail
From: lvir...@yahoo.com
Newsgroups: comp.mail.misc,comp.programming,comp.lang.tcl,comp.lang.perl.misc
Subject: Re: How can a SMTP mail be deleted from a Unix mailbox by a script?
Date: 20 Jan 2003 13:25:44 GMT
Organization: CAS, Columbus, Ohio
Lines: 58
Message-ID: <b0gtco$d3v$1@srv38.cas.org>
References: <40ed1d8f.0301181354.4738f7dc@posting.google.com>
Reply-To: lvir...@yahoo.com
NNTP-Posting-Host: lwv26awu.cas.org
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
X-Newsreader: trn 4.0-test76 (Apr 2, 2001)
Originator: lw...@cas.org (Larry W. Virden)


According to Markus Elfring <Markus.Elfr...@web.de>:
:This request's subject is the deletion of messages in the file "mbox".

:The deletion can be performed manually by typing the letter "d" with a
:following message number inside the programmes "mail". (This step can
:be performed by a script, too.)
:
:I encounter the difficulty to scroll through all exististing messages
:by a command to find the right number for the message that should be
:deleted. I am looking for an efficient algorithm.

I don't believe that the format that the physical storage of mail messages
within a file is documented in a standard.  Neither, unfortunately, is
the protocol for interacting with such a file.  This leaves one wanting
to do things with the box in a quandry.  First, one has no guaranteed way
of knowing how the messages are stored - are they merely a series of 
messages appended one to another, with perhaps some sort of initial line
indicating something about the message (the most frequent case in open source
software at least)?  Does the format consist, instead of seperator lines,
of the software making use of some particular header (under System V, some
mailers make use of a content-length header to determine where the end of a
msg occurred)?  Or does the file format consist of some sort of lead in
index?  Or, as is the case for some user mail agent packages, does each message
become stored in its own file?

The second problem is even worse, in my opinion.  That is the factor of file
locking.  Each mail program is free to (and appears to) make use of what
its author(s) deem as most useful file locking.  Of course, if one's
mail files are on NFS, then some file locking schemes are less successful
than others.  But if an additional utility to, say, delete messages, were
to be written, the author needs to account for the locking styles of ANY
program which might update that box, so as not to lose messages.

If the above two problems were solvable, then the method to 'delete'
a message would be to write to a new file all the messages before, and after,
the message in question to a file.  The author would probably open the
original file for exclusive access, read in the data and write out the 
remaining messages to a new file, then somehow rename the two files in
a way that would minimize the window one might lose a message.

It is a non-trivial task to do right.

:3.2 The file can always be written (without the deleted contents) to a
:new version. The updated version replaces the old one. Is this
:applicable if you think about speed?

Unfortunately, there are no options, at least on Unix and given the
above restrictions.

Besides storing each message in a seperate file, another option might be
to store emails in a database (ala Outlook, etc.)

-- 
Tcl - The glue of a new generation.  <URL: http://wiki.tcl.tk/ >
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
<URL: mailto:lvir...@yahoo.com > <URL: http://www.purl.org/NET/lvirden/ >