[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#33005: 27.0.50; Data loss with Gnus registry
From: |
Eric Abrahamsen |
Subject: |
bug#33005: 27.0.50; Data loss with Gnus registry |
Date: |
Thu, 28 Nov 2019 23:55:59 +0000 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
Michael Heerdegen <michael_heerdegen@web.de> writes:
> Eric Abrahamsen <eric@ericabrahamsen.net> 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.
- bug#33005: 27.0.50; Data loss with Gnus registry, (continued)
- bug#33005: 27.0.50; Data loss with Gnus registry, Eric Abrahamsen, 2019/11/25
- bug#33005: 27.0.50; Data loss with Gnus registry, Michael Heerdegen, 2019/11/26
- bug#33005: 27.0.50; Data loss with Gnus registry, Eric Abrahamsen, 2019/11/26
- bug#33005: 27.0.50; Data loss with Gnus registry, Michael Heerdegen, 2019/11/26
- bug#33005: 27.0.50; Data loss with Gnus registry, Eric Abrahamsen, 2019/11/26
- bug#33005: 27.0.50; Data loss with Gnus registry, Michael Heerdegen, 2019/11/26
- bug#33005: 27.0.50; Data loss with Gnus registry, Eric Abrahamsen, 2019/11/26
- bug#33005: 27.0.50; Data loss with Gnus registry, Michael Heerdegen, 2019/11/26
- bug#33005: 27.0.50; Data loss with Gnus registry, Eric Abrahamsen, 2019/11/28
- bug#33005: 27.0.50; Data loss with Gnus registry, Michael Heerdegen, 2019/11/28
- bug#33005: 27.0.50; Data loss with Gnus registry,
Eric Abrahamsen <=
- bug#33005: 27.0.50; Data loss with Gnus registry, Michael Heerdegen, 2019/11/29