On Sun, 28 Apr 2013 00:24:28 +0300, Jani Nikula <jani@nikula.org> wrote:
> On Wed, 03 Apr 2013, Peter Wang <novalazy@gmail.com> wrote:
> > The notmuch insert command reads a message from standard input,
> > writes it to a Maildir folder, and then incorporates the message into
> > the notmuch database.  Essentially it moves the functionality of
> > notmuch-deliver into notmuch.
> >
> > Though it could be used as an alternative to notmuch new, the reason
> > I want this is to allow my notmuch frontend to add postponed or sent
> > messages to the mail store and notmuch database, without resorting to
> > another tool (e.g. notmuch-deliver) nor directly modifying the maildir.
> > ---
> >  Makefile.local   |   1 +
> >  notmuch-client.h |   3 +
> >  notmuch-insert.c | 336 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >  notmuch.c        |   3 +
> >  4 files changed, 343 insertions(+)
> >  create mode 100644 notmuch-insert.c
> >
...
> > +/* Add the specified message file to the notmuch database, applying tags.
> > + * The file is renamed to encode notmuch tags as maildir flags. */
> > +static notmuch_bool_t
> > +add_file_to_database (notmuch_database_t *notmuch, const char *path,
> > +		      tag_op_list_t *tag_ops)
> > +{
> > +    notmuch_message_t *message;
> > +    notmuch_status_t status;
> > +
> > +    status = notmuch_database_add_message (notmuch, path, &message);
> > +    switch (status) {
> > +    case NOTMUCH_STATUS_SUCCESS:
> > +    case NOTMUCH_STATUS_DUPLICATE_MESSAGE_ID:
> > +	break;
> > +    default:
> > +    case NOTMUCH_STATUS_FILE_NOT_EMAIL:
> 
> If such a message really arrives, the mail system will keep trying if
> failure is returned. Maybe deliver the file without indexing, and return
> success?
> 

Rethinking it, if notmuch insert is going to used as a general mail
delivery tool (not my own use case) then its primary job should be to
get the file to disk.  As long as that is done, we should return success.

Indexing the message would be considered a bonus, and failure there
or in syncing tags to flags should not cause the file to be deleted and
an error code returned.  (A warning can be written to standard error.)

> > +    case NOTMUCH_STATUS_READ_ONLY_DATABASE:
> > +    case NOTMUCH_STATUS_XAPIAN_EXCEPTION:
> > +    case NOTMUCH_STATUS_OUT_OF_MEMORY:
> > +    case NOTMUCH_STATUS_FILE_ERROR:
> > +    case NOTMUCH_STATUS_NULL_POINTER:
> > +    case NOTMUCH_STATUS_TAG_TOO_LONG:
> > +    case NOTMUCH_STATUS_UNBALANCED_FREEZE_THAW:
> > +    case NOTMUCH_STATUS_UNBALANCED_ATOMIC:
> > +    case NOTMUCH_STATUS_LAST_STATUS:
> > +	fprintf (stderr, "Error: failed to add `%s' to notmuch database: %s\n",
> > +		 path, notmuch_status_to_string (status));
> > +	return FALSE;
> > +    }
> > +
> > +    if (status == NOTMUCH_STATUS_DUPLICATE_MESSAGE_ID) {
> > +	/* Don't change tags of an existing message. */
> > +	status = notmuch_message_tags_to_maildir_flags (message);
> > +	if (status != NOTMUCH_STATUS_SUCCESS)
> > +	    fprintf (stderr, "Error: failed to sync tags to maildir flags\n");
> > +    } else {
> > +	status = tag_op_list_apply (message, tag_ops, TAG_FLAG_MAILDIR_SYNC);
> 
> Syncing tags to maildir flags is more interesting here than above. And
> it should be done because notmuch insert allows arbitrary tags on the
> command line. Having, for example, -unread or +flagged on the command
> line makes the flags go out of sync. (notmuch new should do the syncing
> too, but it's less important because it only adds new.tags.)
> 
> However, calling notmuch_message_tags_to_maildir_flags() may rename the
> file from new to cur, which blows up the directory syncing and file
> unlinking on the error path in insert_message() below.

We would sidestep these problems.

> > +static notmuch_bool_t
> > +insert_message (void *ctx, notmuch_database_t *notmuch, int fdin,
> > +		const char *dir, tag_op_list_t *tag_ops)
> > +{
> > +    char *tmppath;
> > +    char *newpath;
> > +    char *newdir;
> > +    int fdout;
> > +    char *cleanup_path;
> > +
> > +    fdout = maildir_open_tmp_file (ctx, dir, &tmppath, &newpath, &newdir);
> > +    if (fdout < 0)
> > +	return FALSE;
> > +
> > +    cleanup_path = tmppath;
> > +
> > +    if (! copy_stdin (fdin, fdout))
> > +	goto FAIL;
> > +
> > +    if (fsync (fdout) != 0) {
> > +	fprintf (stderr, "Error: fsync failed: %s\n", strerror (errno));
> > +	goto FAIL;
> > +    }
> > +
> > +    close (fdout);
> > +    fdout = -1;
> > +
> > +    /* Atomically move the new message file from the Maildir 'tmp' directory
> > +     * to the 'new' directory.  We follow the Dovecot recommendation to
> > +     * simply use rename() instead of link() and unlink().
> > +     * See also: http://wiki.dovecot.org/MailboxFormat/Maildir#Mail_delivery
> > +     */
> > +    if (rename (tmppath, newpath) != 0) {
> > +	fprintf (stderr, "Error: rename() failed: %s\n", strerror (errno));
> > +	goto FAIL;
> > +    }
> > +
> > +    cleanup_path = newpath;
> > +
> > +    if (! add_file_to_database (notmuch, newpath, tag_ops)) {
> > +	/* XXX add an option to keep the file in maildir? */
> 
> Possibly a good idea to let the user decide. This is the part that I
> worry most about in the series. It's not unusual to hit xapian
> exceptions when the database is already locked, which results
> (hopefully!) in another attempt at delivery. If not, mail is lost.
> 
> However, keeping the file in maildir on indexing errors ignores the tags
> specified on the notmuch insert command line, and the message will get
> just new.tags next time notmuch new is run. This is not nice either.

Not sure what else could be done.

Peter