--- /dev/null
+Return-Path: <novalazy@gmail.com>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+ by olra.theworths.org (Postfix) with ESMTP id 76529431FAF\r
+ for <notmuch@notmuchmail.org>; Tue, 28 May 2013 06:59:14 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -0.099\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5\r
+ tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,\r
+ FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=disabled\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+ by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+ with ESMTP id oJFqyr+g1NNd for <notmuch@notmuchmail.org>;\r
+ Tue, 28 May 2013 06:59:04 -0700 (PDT)\r
+Received: from mail-pd0-f176.google.com (mail-pd0-f176.google.com\r
+ [209.85.192.176]) (using TLSv1 with cipher RC4-SHA (128/128 bits))\r
+ (No client certificate requested)\r
+ by olra.theworths.org (Postfix) with ESMTPS id 87309431FAE\r
+ for <notmuch@notmuchmail.org>; Tue, 28 May 2013 06:59:04 -0700 (PDT)\r
+Received: by mail-pd0-f176.google.com with SMTP id r11so7618348pdi.21\r
+ for <notmuch@notmuchmail.org>; Tue, 28 May 2013 06:59:02 -0700 (PDT)\r
+DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;\r
+ h=date:message-id:from:to:cc:subject:in-reply-to:references\r
+ :mime-version:content-type:content-disposition\r
+ :content-transfer-encoding;\r
+ bh=8lUzYxPqsl9CVde2gMByvB4r4rbOjTr/fHQOV7ys2fc=;\r
+ b=0Czw2bvxjImWP4KjtxwoJhdMH8xp9ZEXUwQBukr+3VnIq13FxnK3JdWmaHCHiOTHDS\r
+ /MVZYccjaEzw+CkIOzo+HTxqbD/MPZzEin0GlgTfcv5A2Tvoyxs1/1B3J7R86PbLdZjB\r
+ xqFzBsl9ZYxu6nWh4w7UBuegGCL/E2S78c/eFdhbywkhUwSpMvR3dzpn/YTSk4VCq2z4\r
+ IVaNMj6zXnWZyEHZaYrb2aEnSQZfIE8YiAtNK4MS8cYB3q5+W9cEXCKdHeXwDApo6gt7\r
+ Ltn0g0p+Tdb75tqmc37/GzDvEqmuoBul7yx8J4gsvBbcd7Ld8ogDmA4kbBvUbbeq8Svm\r
+ gHuw==\r
+X-Received: by 10.68.222.74 with SMTP id qk10mr34022999pbc.58.1369749542622;\r
+ Tue, 28 May 2013 06:59:02 -0700 (PDT)\r
+Received: from localhost (215.42.233.220.static.exetel.com.au.\r
+ [220.233.42.215]) by mx.google.com with ESMTPSA id\r
+ cp1sm32982475pbc.42.2013.05.28.06.58.58 for <multiple recipients>\r
+ (version=TLSv1.2 cipher=RC4-SHA bits=128/128);\r
+ Tue, 28 May 2013 06:59:01 -0700 (PDT)\r
+Date: Tue, 28 May 2013 23:58:55 +1000\r
+Message-ID: <20130528235855.GB3209@hili.localdomain>\r
+From: Peter Wang <novalazy@gmail.com>\r
+To: Jani Nikula <jani@nikula.org>\r
+Subject: Re: [PATCH v5 03/12] cli: add insert command\r
+In-Reply-To: <8761z7r7jn.fsf@nikula.org>\r
+References: <1364942517-6982-1-git-send-email-novalazy@gmail.com>\r
+ <1364942517-6982-4-git-send-email-novalazy@gmail.com>\r
+ <8761z7r7jn.fsf@nikula.org>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain; charset=utf-8\r
+Content-Disposition: inline\r
+Content-Transfer-Encoding: 8bit\r
+Cc: notmuch@notmuchmail.org\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+ <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Tue, 28 May 2013 13:59:14 -0000\r
+\r
+On Sun, 28 Apr 2013 00:24:28 +0300, Jani Nikula <jani@nikula.org> wrote:\r
+> On Wed, 03 Apr 2013, Peter Wang <novalazy@gmail.com> wrote:\r
+> > The notmuch insert command reads a message from standard input,\r
+> > writes it to a Maildir folder, and then incorporates the message into\r
+> > the notmuch database. Essentially it moves the functionality of\r
+> > notmuch-deliver into notmuch.\r
+> >\r
+> > Though it could be used as an alternative to notmuch new, the reason\r
+> > I want this is to allow my notmuch frontend to add postponed or sent\r
+> > messages to the mail store and notmuch database, without resorting to\r
+> > another tool (e.g. notmuch-deliver) nor directly modifying the maildir.\r
+> > ---\r
+> > Makefile.local | 1 +\r
+> > notmuch-client.h | 3 +\r
+> > notmuch-insert.c | 336 +++++++++++++++++++++++++++++++++++++++++++++++++++++++\r
+> > notmuch.c | 3 +\r
+> > 4 files changed, 343 insertions(+)\r
+> > create mode 100644 notmuch-insert.c\r
+> >\r
+...\r
+> > +/* Add the specified message file to the notmuch database, applying tags.\r
+> > + * The file is renamed to encode notmuch tags as maildir flags. */\r
+> > +static notmuch_bool_t\r
+> > +add_file_to_database (notmuch_database_t *notmuch, const char *path,\r
+> > + tag_op_list_t *tag_ops)\r
+> > +{\r
+> > + notmuch_message_t *message;\r
+> > + notmuch_status_t status;\r
+> > +\r
+> > + status = notmuch_database_add_message (notmuch, path, &message);\r
+> > + switch (status) {\r
+> > + case NOTMUCH_STATUS_SUCCESS:\r
+> > + case NOTMUCH_STATUS_DUPLICATE_MESSAGE_ID:\r
+> > + break;\r
+> > + default:\r
+> > + case NOTMUCH_STATUS_FILE_NOT_EMAIL:\r
+> \r
+> If such a message really arrives, the mail system will keep trying if\r
+> failure is returned. Maybe deliver the file without indexing, and return\r
+> success?\r
+> \r
+\r
+Rethinking it, if notmuch insert is going to used as a general mail\r
+delivery tool (not my own use case) then its primary job should be to\r
+get the file to disk. As long as that is done, we should return success.\r
+\r
+Indexing the message would be considered a bonus, and failure there\r
+or in syncing tags to flags should not cause the file to be deleted and\r
+an error code returned. (A warning can be written to standard error.)\r
+\r
+> > + case NOTMUCH_STATUS_READ_ONLY_DATABASE:\r
+> > + case NOTMUCH_STATUS_XAPIAN_EXCEPTION:\r
+> > + case NOTMUCH_STATUS_OUT_OF_MEMORY:\r
+> > + case NOTMUCH_STATUS_FILE_ERROR:\r
+> > + case NOTMUCH_STATUS_NULL_POINTER:\r
+> > + case NOTMUCH_STATUS_TAG_TOO_LONG:\r
+> > + case NOTMUCH_STATUS_UNBALANCED_FREEZE_THAW:\r
+> > + case NOTMUCH_STATUS_UNBALANCED_ATOMIC:\r
+> > + case NOTMUCH_STATUS_LAST_STATUS:\r
+> > + fprintf (stderr, "Error: failed to add `%s' to notmuch database: %s\n",\r
+> > + path, notmuch_status_to_string (status));\r
+> > + return FALSE;\r
+> > + }\r
+> > +\r
+> > + if (status == NOTMUCH_STATUS_DUPLICATE_MESSAGE_ID) {\r
+> > + /* Don't change tags of an existing message. */\r
+> > + status = notmuch_message_tags_to_maildir_flags (message);\r
+> > + if (status != NOTMUCH_STATUS_SUCCESS)\r
+> > + fprintf (stderr, "Error: failed to sync tags to maildir flags\n");\r
+> > + } else {\r
+> > + status = tag_op_list_apply (message, tag_ops, TAG_FLAG_MAILDIR_SYNC);\r
+> \r
+> Syncing tags to maildir flags is more interesting here than above. And\r
+> it should be done because notmuch insert allows arbitrary tags on the\r
+> command line. Having, for example, -unread or +flagged on the command\r
+> line makes the flags go out of sync. (notmuch new should do the syncing\r
+> too, but it's less important because it only adds new.tags.)\r
+> \r
+> However, calling notmuch_message_tags_to_maildir_flags() may rename the\r
+> file from new to cur, which blows up the directory syncing and file\r
+> unlinking on the error path in insert_message() below.\r
+\r
+We would sidestep these problems.\r
+\r
+> > +static notmuch_bool_t\r
+> > +insert_message (void *ctx, notmuch_database_t *notmuch, int fdin,\r
+> > + const char *dir, tag_op_list_t *tag_ops)\r
+> > +{\r
+> > + char *tmppath;\r
+> > + char *newpath;\r
+> > + char *newdir;\r
+> > + int fdout;\r
+> > + char *cleanup_path;\r
+> > +\r
+> > + fdout = maildir_open_tmp_file (ctx, dir, &tmppath, &newpath, &newdir);\r
+> > + if (fdout < 0)\r
+> > + return FALSE;\r
+> > +\r
+> > + cleanup_path = tmppath;\r
+> > +\r
+> > + if (! copy_stdin (fdin, fdout))\r
+> > + goto FAIL;\r
+> > +\r
+> > + if (fsync (fdout) != 0) {\r
+> > + fprintf (stderr, "Error: fsync failed: %s\n", strerror (errno));\r
+> > + goto FAIL;\r
+> > + }\r
+> > +\r
+> > + close (fdout);\r
+> > + fdout = -1;\r
+> > +\r
+> > + /* Atomically move the new message file from the Maildir 'tmp' directory\r
+> > + * to the 'new' directory. We follow the Dovecot recommendation to\r
+> > + * simply use rename() instead of link() and unlink().\r
+> > + * See also: http://wiki.dovecot.org/MailboxFormat/Maildir#Mail_delivery\r
+> > + */\r
+> > + if (rename (tmppath, newpath) != 0) {\r
+> > + fprintf (stderr, "Error: rename() failed: %s\n", strerror (errno));\r
+> > + goto FAIL;\r
+> > + }\r
+> > +\r
+> > + cleanup_path = newpath;\r
+> > +\r
+> > + if (! add_file_to_database (notmuch, newpath, tag_ops)) {\r
+> > + /* XXX add an option to keep the file in maildir? */\r
+> \r
+> Possibly a good idea to let the user decide. This is the part that I\r
+> worry most about in the series. It's not unusual to hit xapian\r
+> exceptions when the database is already locked, which results\r
+> (hopefully!) in another attempt at delivery. If not, mail is lost.\r
+> \r
+> However, keeping the file in maildir on indexing errors ignores the tags\r
+> specified on the notmuch insert command line, and the message will get\r
+> just new.tags next time notmuch new is run. This is not nice either.\r
+\r
+Not sure what else could be done.\r
+\r
+Peter\r
projects / notmuch-archives.git / commitdiff