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 132476DE098B for ; Tue, 2 Jan 2018 17:01:13 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at cworth.org X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[AWL=0.011, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 LFX53Uu7WE2P for ; Tue, 2 Jan 2018 17:01:12 -0800 (PST) Received: from fethera.tethera.net (fethera.tethera.net [198.245.60.197]) by arlo.cworth.org (Postfix) with ESMTPS id 220A36DE0243 for ; Tue, 2 Jan 2018 17:01:12 -0800 (PST) Received: from remotemail by fethera.tethera.net with local (Exim 4.89) (envelope-from ) id 1eWXQd-0004oU-6E; Tue, 02 Jan 2018 20:01:11 -0500 Received: (nullmailer pid 25057 invoked by uid 1000); Wed, 03 Jan 2018 01:01:10 -0000 From: David Bremner To: Daniel Kahn Gillmor , notmuch@notmuchmail.org Subject: Re: [PATCH] WIP: support XDG database directory In-Reply-To: <87r2r7epsx.fsf@fifthhorseman.net> References: <20171230200740.22509-1-david@tethera.net> <877eszg8fv.fsf@fifthhorseman.net> <87a7xv3j6m.fsf@tethera.net> <87r2r7epsx.fsf@fifthhorseman.net> Date: Tue, 02 Jan 2018 21:01:10 -0400 Message-ID: <87y3lf21t5.fsf@tethera.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 01:01:13 -0000 Daniel Kahn Gillmor writes: > > 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. Right, with the possibility of the user overriding the maildir, at least at the library level.=20 > 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 ("=E2=80=A6because you mounted the USB stick at /Media= /foo > instead of /Volumes/foo") scenario? That's something that needs to be thought through. Essentially the same issue I mentioned. d