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 190EA431FB6 for ; Fri, 26 Sep 2014 13:09:35 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] 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 T51JSThpj0WA for ; Fri, 26 Sep 2014 13:09:31 -0700 (PDT) Received: from yantan.tethera.net (yantan.tethera.net [199.188.72.155]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by olra.theworths.org (Postfix) with ESMTPS id 4F58C431FAF for ; Fri, 26 Sep 2014 13:09:31 -0700 (PDT) Received: from remotemail by yantan.tethera.net with local (Exim 4.80) (envelope-from ) id 1XXbpR-0000ZR-I9; Fri, 26 Sep 2014 17:09:21 -0300 Received: (nullmailer pid 9379 invoked by uid 1000); Fri, 26 Sep 2014 20:09:16 -0000 From: David Bremner To: Jani Nikula , notmuch@notmuchmail.org Subject: Re: [PATCH 09/11] cli/insert: add fail path to add_file_to_database In-Reply-To: <5089ce31afa0ba764520270af1e680a4ab50b4e6.1411379395.git.jani@nikula.org> References: <5089ce31afa0ba764520270af1e680a4ab50b4e6.1411379395.git.jani@nikula.org> User-Agent: Notmuch/0.18.1+98~gae27403 (http://notmuchmail.org) Emacs/24.3.1 (x86_64-pc-linux-gnu) Date: Fri, 26 Sep 2014 22:09:16 +0200 Message-ID: <87eguyf8k3.fsf@maritornes.cs.unb.ca> MIME-Version: 1.0 Content-Type: text/plain 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: Fri, 26 Sep 2014 20:09:35 -0000 Jani Nikula writes: > + status = notmuch_message_tags_to_maildir_flags (message); ... > + /* > + * Note: Unfortunately a failed maildir flag sync might > + * already have renamed the file, in which case the cleanup > + * path will fail. > + */ I'd like to be more explicit about what potentially bad outcomes there are here. I guess this message file gets left on disk, unindexed, perhaps forever if the user never runs notmuch new? Would it make sense to suggest the user run notmuch new to "recover" these message files?