Return-Path: X-Original-To: notmuch@notmuchmail.org Delivered-To: notmuch@notmuchmail.org Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id 6A2AF431FAF for ; Mon, 16 Apr 2012 08:52:57 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -1.098 X-Spam-Level: X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5 tests=[DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=1.2, RCVD_IN_DNSWL_MED=-2.3] autolearn=disabled Received: from olra.theworths.org ([127.0.0.1]) by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PCwK7jBgW4sL for ; Mon, 16 Apr 2012 08:52:55 -0700 (PDT) Received: from mail2.qmul.ac.uk (mail2.qmul.ac.uk [138.37.6.6]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by olra.theworths.org (Postfix) with ESMTPS id A92F7431FAE for ; Mon, 16 Apr 2012 08:52:55 -0700 (PDT) Received: from smtp.qmul.ac.uk ([138.37.6.40]) by mail2.qmul.ac.uk with esmtp (Exim 4.71) (envelope-from ) id 1SJoEV-0001Au-C9; Mon, 16 Apr 2012 16:52:54 +0100 Received: from 94-192-233-223.zone6.bethere.co.uk ([94.192.233.223] helo=localhost) by smtp.qmul.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1SJoEV-0005AI-1a; Mon, 16 Apr 2012 16:52:51 +0100 From: Mark Walters To: Austin Clements , notmuch@notmuchmail.org Subject: Re: [PATCH 1/3] new: Consistently treat fatal errors as fatal In-Reply-To: <1330357759-1337-2-git-send-email-amdragon@mit.edu> References: <1330357759-1337-1-git-send-email-amdragon@mit.edu> <1330357759-1337-2-git-send-email-amdragon@mit.edu> User-Agent: Notmuch/0.12+110~gbc97b4a (http://notmuchmail.org) Emacs/23.3.1 (x86_64-pc-linux-gnu) Date: Mon, 16 Apr 2012 16:53:10 +0100 Message-ID: <87zkab4qs9.fsf@qmul.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender-Host-Address: 94.192.233.223 X-QM-SPAM-Info: Sender has good ham record. :) X-QM-Body-MD5: fdaff784e11779ab29d77ded90ba2f51 (of first 20000 bytes) X-SpamAssassin-Score: -1.8 X-SpamAssassin-SpamBar: - X-SpamAssassin-Report: The QM spam filters have analysed this message to determine if it is spam. We require at least 5.0 points to mark a message as spam. This message scored -1.8 points. Summary of the scoring: * -2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/, * medium trust * [138.37.6.40 listed in list.dnswl.org] * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider * (markwalters1009[at]gmail.com) * -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay * domain * 0.5 AWL AWL: From: address is in the auto white-list X-QM-Scan-Virus: ClamAV says the message is clean X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 15:52:57 -0000 On Mon, 27 Feb 2012, Austin Clements wrote: > Previously, fatal errors in add_files_recursive were not treated as > fatal by its callers (including itself!) and add_files_recursive > sometimes returned errors on non-fatal conditions. This makes > add_files_recursive errors consistently fatal and updates all callers > to treat them as fatal. Hi I have attempted to review this but am feeling a little out of my depth. This patch seems fine except for one thing I am unsure about: > --- > notmuch-new.c | 13 ++++++++----- > 1 files changed, 8 insertions(+), 5 deletions(-) > > diff --git a/notmuch-new.c b/notmuch-new.c > index 4f13535..bd9786a 100644 > --- a/notmuch-new.c > +++ b/notmuch-new.c > @@ -308,7 +308,6 @@ add_files_recursive (notmuch_database_t *notmuch, > if (num_fs_entries == -1) { > fprintf (stderr, "Error opening directory %s: %s\n", > path, strerror (errno)); > - ret = NOTMUCH_STATUS_FILE_ERROR; > goto DONE; > } > If I understand this, then this change makes a failure to open a directory non-fatal. In the comment before the function it says * Also, we don't immediately act on file/directory removal since we * must ensure that in the case of a rename that the new filename is * added before the old filename is removed, (so that no information * is lost from the database). I am worried that we could fail to find some files because of the file error above, and then we delete them from the database. Maybe this could only happen if those emails have just been moved to this file-error directory? Best wishes Mark > @@ -351,8 +350,10 @@ add_files_recursive (notmuch_database_t *notmuch, > > next = talloc_asprintf (notmuch, "%s/%s", path, entry->d_name); > status = add_files_recursive (notmuch, next, state); > - if (status && ret == NOTMUCH_STATUS_SUCCESS) > + if (status) { > ret = status; > + goto DONE; > + } > talloc_free (next); > next = NULL; > } > @@ -933,6 +934,8 @@ notmuch_new_command (void *ctx, int argc, char *argv[]) > } > > ret = add_files (notmuch, db_path, &add_files_state); > + if (ret) > + goto DONE; > > gettimeofday (&tv_start, NULL); > for (f = add_files_state.removed_files->head; f && !interrupted; f = f->next) { > @@ -965,6 +968,7 @@ notmuch_new_command (void *ctx, int argc, char *argv[]) > } > } > > + DONE: > talloc_free (add_files_state.removed_files); > talloc_free (add_files_state.removed_directories); > talloc_free (add_files_state.directory_mtimes); > @@ -1012,10 +1016,9 @@ notmuch_new_command (void *ctx, int argc, char *argv[]) > > printf ("\n"); > > - if (ret) { > - printf ("\nNote: At least one error was encountered: %s\n", > + if (ret) > + printf ("\nNote: A fatal error was encountered: %s\n", > notmuch_status_to_string (ret)); > - } > > notmuch_database_close (notmuch); > > -- > 1.7.7.3 > > _______________________________________________ > notmuch mailing list > notmuch@notmuchmail.org > http://notmuchmail.org/mailman/listinfo/notmuch