From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Paul Pogonyshev Newsgroups: gmane.emacs.bugs Subject: bug#41489: `package-dir-info' fails on a directory with a non-saved file Date: Tue, 26 May 2020 08:54:00 +0200 Message-ID: References: <83wo52y0h8.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000011cc6c05a6879029" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="54472"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 41489@debbugs.gnu.org To: Stefan Kangas Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue May 26 08:55:19 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jdTUd-000E48-6o for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 26 May 2020 08:55:19 +0200 Original-Received: from localhost ([::1]:47040 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jdTUc-0007gB-89 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 26 May 2020 02:55:18 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37926) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jdTUN-0007SV-AS for bug-gnu-emacs@gnu.org; Tue, 26 May 2020 02:55:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:60534) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jdTUM-0008JI-V1 for bug-gnu-emacs@gnu.org; Tue, 26 May 2020 02:55:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jdTUM-00058L-V8 for bug-gnu-emacs@gnu.org; Tue, 26 May 2020 02:55:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Paul Pogonyshev Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 26 May 2020 06:55:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 41489 X-GNU-PR-Package: emacs Original-Received: via spool by 41489-submit@debbugs.gnu.org id=B41489.159047606019662 (code B ref 41489); Tue, 26 May 2020 06:55:02 +0000 Original-Received: (at 41489) by debbugs.gnu.org; 26 May 2020 06:54:20 +0000 Original-Received: from localhost ([127.0.0.1]:43843 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jdTTf-00056y-At for submit@debbugs.gnu.org; Tue, 26 May 2020 02:54:19 -0400 Original-Received: from mail-wr1-f66.google.com ([209.85.221.66]:38688) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jdTTd-00056k-Bh for 41489@debbugs.gnu.org; Tue, 26 May 2020 02:54:18 -0400 Original-Received: by mail-wr1-f66.google.com with SMTP id e1so19263865wrt.5 for <41489@debbugs.gnu.org>; Mon, 25 May 2020 23:54:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vwKGyu/lI8MqtSUFWMOKlgUyaGk8Z13efNl1yj9GVzc=; b=DW6lONdTJz/RvCKmqSdV/2SN8lC7L3gwVm5n3+fRuWvLUZ1REWLsR77/mSL9dHhtmE V4uoHYmLyiFr8LB3Rrt/0pEoUQT0PXq+RdETG06WVhIQhho/rszrhVVX/qgmSDVS9U2E HV4BCM6wUJQP5i45jSs98V1Vs6KRcLqXWeqlXn5/bcLCayLEK3N3fLG2PYEhr4vzheKr FyyXHbJFJqcCfaoC6vTlfhoZPegmOVOTXaGacTKdd+y6phA3SqnFS3f2dcA1EWC+j1hp 7Jk1PUhk1w3atoZEPq6S18/qXfzLsimzLaLQVSoQCKIUeVfAAS7T773VRfWFS3T05knd 7neg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vwKGyu/lI8MqtSUFWMOKlgUyaGk8Z13efNl1yj9GVzc=; b=P8Q+pt5pkVn2CZDkPgqI1YN4Uijp44vXJNAg97duzoXVvnoA8gZmN3xVkyifcSf6kp mxlVNIhbBoLNWa1JanOPxJCIwOZQorum3TV1/ePefB1MDpUOt1eJzijGz2TggMs8Gf91 tCMUSK0jZU4yZa1T9UQE3vr/Pc/VJSyiHvRLr9amsIQ530UXlslCTKBangbJbQ8Aj+pf ZrXtSd87qeLPiUCmfGNHOEI93HwPmgvizKpXf52HOyQv8mRj1mVz36UjrRA221EJTnou 9OVV22c2exQGdf6ja689GR5FdfpBHnuA2ixIO0me5kCsUBFnVtDB6kjefB+jcUkaSSls g/pw== X-Gm-Message-State: AOAM532iy/5/Sa6Yn7WrfDJmt7fkhocj0ovF1rQdkO79F+/7q0/0ta4N cZNlN3eUY3PNoMxyXl+beaMopE1oloiR+X5AQw== X-Google-Smtp-Source: ABdhPJy5uP9njuKE5aluXEpCLRKhj5Ox7vX7jeW//OSZWA+g+RfOfUD6BJfgPnN3Kt9zCAMW/YJZEJrnBheyKVGaQ5o= X-Received: by 2002:a5d:42cd:: with SMTP id t13mr18227043wrr.355.1590476051433; Mon, 25 May 2020 23:54:11 -0700 (PDT) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:181022 Archived-At: --00000000000011cc6c05a6879029 Content-Type: text/plain; charset="UTF-8" > Do we really want to ignore *any* error from insert-file-contents here? Well, maybe that should be limited to `file-missing' instead (what actually happens when it tries to read a lock file). > Should we really run package-buffer-info if inserting the file fails? > Won't that reach (error "Package lacks a file header") and signal an > error anyways, just a different and more cryptic one? `package-buffer-info' is already inside a different `ignore-errors', so it will signal an error, but that error will be ignored and the file skipped. I'm not attached to any particular way this bug is fixed. Please adjust it yourself, the patch is only an example of how it could be done. This will be faster than if we try to negotiate the best way and recreate the patch. BTW, the bug being reproducible only in 50% of the cases makes it even more important to be fixed from my point of view. Nothing is worse than unspecified behavior when it's not justified by reasons like huge performance gain in my opinion. Paul On Tue, 26 May 2020 at 04:07, Stefan Kangas wrote: > Paul Pogonyshev writes: > > > diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el > > index 9a6d1d7319..99ba5d7107 100644 > > --- a/lisp/emacs-lisp/package.el > > +++ b/lisp/emacs-lisp/package.el > > @@ -1181,7 +1181,9 @@ package-dir-info > > info) > > (while files > > (with-temp-buffer > > - (insert-file-contents (pop files)) > > + ;; Skip unreadable files, e.g. locks for unsaved `.el' > > + ;; buffers (bug#41489). > > + (ignore-errors (insert-file-contents (pop files))) > > ;; When we find the file with the data, > > (when (setq info (ignore-errors (package-buffer-info))) > > ;; stop looping, > > Do we really want to ignore *any* error from insert-file-contents here? > > Should we really run package-buffer-info if inserting the file fails? > Won't that reach (error "Package lacks a file header") and signal an > error anyways, just a different and more cryptic one? > > Best regards, > Stefan Kangas > --00000000000011cc6c05a6879029 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> Do we really want to ignore *any* error from insert-f= ile-contents here?

Well, maybe that should be limite= d to `file-missing' instead (what actually happens when it tries to rea= d a lock file).

> Should we really run package-= buffer-info if inserting the file fails?
> Won't that reach (erro= r "Package lacks a file header") and signal an
> error anyw= ays, just a different and more cryptic one?

`p= ackage-buffer-info' is already inside a different `ignore-errors', = so it will signal an error, but that error will be ignored and the file ski= pped.

I'm not attached to any particular way t= his bug is fixed. Please adjust it yourself, the patch is only an example o= f how it could be done. This will be faster than if we try to negotiate the= best way and recreate the patch.

BTW, the bug bei= ng reproducible only in 50% of the cases makes it even more important to be= fixed from my point of view. Nothing is worse than unspecified behavior wh= en it's not justified by reasons like huge performance gain in my opini= on.

Paul

On Tue, 26 May 2020 at 04:07, Stefan= Kangas <stefankangas@gmail.co= m> wrote:
Paul Pogonyshev <pogonyshev@gmail.com> writes:

> diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el > index 9a6d1d7319..99ba5d7107 100644
> --- a/lisp/emacs-lisp/package.el
> +++ b/lisp/emacs-lisp/package.el
> @@ -1181,7 +1181,9 @@ package-dir-info
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 info)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (while files
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (with-temp-buffer
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (insert-file-contents (pop = files))
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ;; Skip unreadable files, e= .g. locks for unsaved `.el'
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ;; buffers (bug#41489).
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (ignore-errors (insert-file= -contents (pop files)))
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ;; When we find the fi= le with the data,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (when (setq info (igno= re-errors (package-buffer-info)))
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ;; stop looping= ,

Do we really want to ignore *any* error from insert-file-contents here?

Should we really run package-buffer-info if inserting the file fails?
Won't that reach (error "Package lacks a file header") and si= gnal an
error anyways, just a different and more cryptic one?

Best regards,
Stefan Kangas
--00000000000011cc6c05a6879029--