GNU bug report logs - #44701
28.0.50; [feature/native-comp] Use file-truename when building eln path hash

Previous Next

Package: emacs;

Reported by: Tad <tadfisher <at> gmail.com>

Date: Tue, 17 Nov 2020 04:25:01 UTC

Severity: normal

Found in version 28.0.50

Done: Andrea Corallo <akrl <at> sdf.org>

Bug is archived. No further changes may be made.

Full log


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

From: Andrea Corallo <akrl <at> sdf.org>
To: Tad <tadfisher <at> gmail.com>
Cc: 44701 <at> debbugs.gnu.org
Subject: Re: 28.0.50; [feature/native-comp] Use file-truename when building
 eln path hash
Date: Wed, 18 Nov 2020 08:28:20 +0000
Hi Tad,

Tad <tadfisher <at> gmail.com> writes:

> It appears that `comp-el-to-eln-filename` uses `expand-file-name` to
> determine the absolute filename to
> hash. When the filename is a symlink, this results in a cache miss
> depending on which path is loaded.
>
> `file-truename' would be the equivalent to `(expand-file-name name
> nil)`, except that it would resolve to a
> single canonical path (in the absence of hardlinks, which is pathological).

It might be not 100% trivial as just calling `file-truename' from
`comp-el-to-eln-filename' in place of `expand-file-name'.  ATM I'm not
sure is good to call Lisp from there.  I'll give it a go.

> If I may ask, what is the purpose behind the path component of the
> hash? I would think a content hash
> would suffice to disambiguate files in the .el<->.eln bijection.

Sure we mainly use it to keep the eln-cache directory clean when
recompiling.

Thanks for reporting.

  Andrea




This bug report was last modified 4 years and 248 days ago.

Previous Next


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