From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eric Abrahamsen Newsgroups: gmane.emacs.bugs Subject: bug#33005: 27.0.50; Data loss with Gnus registry Date: Thu, 28 Nov 2019 23:55:59 +0000 Message-ID: <87imn3tv1s.fsf@ericabrahamsen.net> References: <871s8yvsrq.fsf@web.de> <87k17nwkxi.fsf@web.de> <8736ebxxwa.fsf@ericabrahamsen.net> <87k17m1tv0.fsf@web.de> <87pnhev5n4.fsf@ericabrahamsen.net> <87sgma1ju2.fsf@web.de> <87imn6v01s.fsf@web.de> <87eexuuznq.fsf@web.de> <87sgm8tmq6.fsf@ericabrahamsen.net> <87wobk0xza.fsf@web.de> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="240538"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: 33005@debbugs.gnu.org To: Michael Heerdegen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Nov 29 01:00:31 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iaTi3-0010QC-Ee for geb-bug-gnu-emacs@m.gmane.org; Fri, 29 Nov 2019 01:00:31 +0100 Original-Received: from localhost ([::1]:54054 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iaTi0-0003gN-Ga for geb-bug-gnu-emacs@m.gmane.org; Thu, 28 Nov 2019 19:00:28 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41410) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iaThW-0003f4-2o for bug-gnu-emacs@gnu.org; Thu, 28 Nov 2019 19:00:03 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iaTeg-0001KR-0x for bug-gnu-emacs@gnu.org; Thu, 28 Nov 2019 18:57:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:53296) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iaTef-0001Jn-Su for bug-gnu-emacs@gnu.org; Thu, 28 Nov 2019 18:57:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iaTef-0005tZ-RT for bug-gnu-emacs@gnu.org; Thu, 28 Nov 2019 18:57:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eric Abrahamsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 28 Nov 2019 23:57:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 33005 X-GNU-PR-Package: emacs Original-Received: via spool by 33005-submit@debbugs.gnu.org id=B33005.157498537222591 (code B ref 33005); Thu, 28 Nov 2019 23:57:01 +0000 Original-Received: (at 33005) by debbugs.gnu.org; 28 Nov 2019 23:56:12 +0000 Original-Received: from localhost ([127.0.0.1]:59269 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iaTds-0005sI-Ge for submit@debbugs.gnu.org; Thu, 28 Nov 2019 18:56:12 -0500 Original-Received: from ericabrahamsen.net ([52.70.2.18]:40140 helo=mail.ericabrahamsen.net) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iaTdq-0005s2-Sb for 33005@debbugs.gnu.org; Thu, 28 Nov 2019 18:56:11 -0500 Original-Received: from localhost (unknown [94.11.255.11]) (Authenticated sender: eric@ericabrahamsen.net) by mail.ericabrahamsen.net (Postfix) with ESMTPSA id E069CFA086; Thu, 28 Nov 2019 23:56:01 +0000 (UTC) In-Reply-To: <87wobk0xza.fsf@web.de> (Michael Heerdegen's message of "Thu, 28 Nov 2019 17:25:29 +0100") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:172631 Archived-At: Michael Heerdegen writes: > Eric Abrahamsen writes: > >> But that still doesn't completely explain why this works. Say a user >> starts Gnus cold, and only loads gnus-registry.el via an autoloaded call >> to `gnus-registry-initialize' in the init file. The shutdowns run before >> the init file is loaded, meaning gnus-registry.el hasn't been loaded, >> meaning it hasn't had a chance to add its registry-related shutdown yet. >> So we should still be loading the registry with an already-initialized >> `gnus-registry-db', and overwriting the user's existing data. > > But that shouldn't be hard to find out with the help of edebug, variable > watchers, etc. - right? No, I just didn't have time between waking up and landing. I'm on a business trip so I haven't had much hacking time. This weekend I should have time. > BTW, are you sure that the behavior you see is seen by anyone else? > Could it be that it works just for you because of your setup? I'd be awfully surprised if it only worked for me -- I'd think we would have seen bug reports by now. I still blame your usage of debbugs-gnu :) >> Obviously the code as it stands should be changed: either I should find >> another way of preventing double loading, or the defvar shouldn't >> initialize the database to anything (I prefer this latter). > > Initializing with an empty database cries for this sort of problem. > This should only be done when loading fails because the save file > doesn't exist. Then the user should be informed that a new empty > database is created. Yes, I agree that initializing to an empty database is a bad idea. All the mechanisms are already in place for detecting when no database has been created, and making a new one -- there's no reason to hang an empty database on there. I'd still like to know exactly what's going on, though. > BTW, what's so problematic with avoiding repeated loading? Can't you > just use a bool var to remember? I thought that the `eieio-object-p' check WAS the equivalent of the "bool var". I hadn't actually seen that the defvar was initialized like that. Anyway, I don't want to make another sloppy mistake. But I do think just leaving the defvar at nil and getting rid of `gnus-registry-make-db' will end up being the solution.