From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by arlo.cworth.org (Postfix) with ESMTP id 6833C6DE098B for ; Tue, 2 Jan 2018 16:54:13 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at cworth.org X-Spam-Flag: NO X-Spam-Score: -0.025 X-Spam-Level: X-Spam-Status: No, score=-0.025 tagged_above=-999 required=5 tests=[AWL=-0.025] autolearn=disabled Received: from arlo.cworth.org ([127.0.0.1]) by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sXmYsA_kggm6 for ; Tue, 2 Jan 2018 16:54:12 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by arlo.cworth.org (Postfix) with ESMTPS id 879736DE0243 for ; Tue, 2 Jan 2018 16:54:12 -0800 (PST) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id DBB5EF99B; Tue, 2 Jan 2018 19:54:11 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 184C720330; Tue, 2 Jan 2018 19:42:07 -0500 (EST) From: Daniel Kahn Gillmor To: David Bremner , notmuch@notmuchmail.org Subject: Re: [PATCH] WIP: support XDG database directory In-Reply-To: <87a7xv3j6m.fsf@tethera.net> References: <20171230200740.22509-1-david@tethera.net> <877eszg8fv.fsf@fifthhorseman.net> <87a7xv3j6m.fsf@tethera.net> Date: Tue, 02 Jan 2018 19:42:06 -0500 Message-ID: <87r2r7epsx.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.23 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: Wed, 03 Jan 2018 00:54:13 -0000 On Tue 2018-01-02 20:00:33 -0400, David Bremner wrote: > Daniel Kahn Gillmor writes: >> where would each such notmuch database live if there were two different >> mailstores? how is any given mailstore bound to the associated notmuch >> database itself? > > Each database would point to the associated maildir_root in this version. > >> does the user point explicitly to both the mailstore >> and the database? > > at the library level, I'm thinking the right API is probably to take > both parameters (database and maildir), and if > > - database_path is NULL => look in traditional .notmuch location > current notmuch_database_open would call something like > notmuch_database_open2 (maildir, NULL). > Presumable with a more informative name. > > - maildir_path is NULL => look in the database for a configuration > > - both are NULL => look in $ENV{NOTMUCH_DATABASE_DIRECTORY} and then > under $ENV{XDG_DATA_HOME}/notmuch, using the database to find the > maildir (essentially this patch) > > This last case is aimed at allowing users of the library to open a > "default" database without the current parsing of .notmuch-config i like the sound of this, but... >> i ask because i've been thinking about ways to protect the index itself, >> but i want to make sure i understand all the different ways that the >> mailstore and the database are (or are not) coupled to each other. > > I guess the initial proposal would be not at all? this doesn't seem like a correct characterization of it, unless we're misunderstanding each other. it looks to me like each notmuch database *would* be coupled with exactly one mailstore, given this proposal. is that right? if the library tried to open the database on its own, it would look at the database's stored maildir_root path. or am i missing something? > That probably allows a few new kinds of user error; I'm imagining > runing notmuch new with mismatched database and maildir, and happily > deleteing all of the database documents. yikes! still, i agree that in general i'd rather point notmuch at the database and have it discover everything it needs to from that; rather than the current approach of the split config file and database, which seems cumbersome and error-prone in other ways. that said, i *definitely* prefer the database identifying the mailstore (as you've done here) rather than the other way around. one final question: for portable databases, which live on a removable volume, or which are on networked-accessible storage and might be mounted in different places on different computers, do we have a way to protect them from the "whoops, mailstore is missing because you are on the wrong host" or ("…because you mounted the USB stick at /Media/foo instead of /Volumes/foo") scenario? --dkg