GNU bug report logs - #78340
[PATCH] New option for comp *.eln file name by the file timestamp of *.el

Previous Next

Full log

Message #14 received at 78340 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lin Sun <sunlin7 <at> hotmail.com>
Cc: acorallo <at> gnu.org, 78340 <at> debbugs.gnu.org
Subject: Re: bug#78340: [PATCH] New option for comp *.eln file name by the
 file timestamp of *.el
Date: Sat, 10 May 2025 18:46:15 +0300

> From: Lin Sun <sunlin7 <at> hotmail.com>
> CC: "78340 <at> debbugs.gnu.org" <78340 <at> debbugs.gnu.org>
> Date: Sat, 10 May 2025 15:28:15 +0000
> 
> > Also, is your anti-virus software configured to ignore *.eln files in
> > the directories where you install them?  The *.eln files are DLLs as
> > far as Windows is concerned, so it's executable code, and anti-virus
> > software will therefore generally scan them when accessed or loaded,
> > which could significantly slow down loading.
> 
> I tested on same environment, with this patch it will speedup Emacs loading files.

I asked specifically about anti-virus: did you try to configure it so
as not to scan the *.eln files?

> >  . it is easy to "fake" file's time using 'touch' 'cp -p' and similar
> >    techniques; in fact, the Emacs "make install" uses that
> >  . on a modern system, it is quite possible to have a newer file have
> >    the same time stamp as an older file, due to relatively low
> >    resolution of file time stamps
> >  . Emacs on MS-Windows has a 1-sec granularity of file time stamps,
> >    which makes the above even worse
> >
> > All of the above means that using the file time stamps risks loading
> > incorrect *.eln files, which could crash Emacs.  So up front, I don't
> > think we should have this feature, on Windows or elsewhere.
> 
> The .eln file is named in filename-X-Y.eln format, timestamp change maybe lead that Emacs can not find the .eln file, then Emacs will use the .elc/.el file, still works.

I'm actually bothered by the false-positive case: when the time stamp
matches, but the file is wrong.  These 2 hashes are there for a very
good reason: loading an incompatible file could cause fatal failures
and loss of data and edits.

> This option gives Emacs user a chance to build a faster Emacs on their local, especially for Emacs on Windows. And it's not a default option, won't bother the user who don't build the Emacs themself.

Sorry, I don't think it's right to add options that could risk
crashing Emacs.  What kind of project are we if we add such options,
even if they are off by default?

So let's wait for Andrea to provide his opinion on this.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.