bug#57562: [PATCH] * lisp/emacs-lisp/comp.el (comp-run-async-workers): Fail more gracefully

[Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Eli Zaretskii [2022-09-03 22:28:20] wrote:

>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Cc: 57562@debbugs.gnu.org
>> Date: Sat, 03 Sep 2022 15:16:23 -0400
>> 
>> > I guess that's enough for Emacs 28.  (And I do wonder how come people
>> > come up with unwritable home directories.)
>> 
>> In the discussion of that Debian bug#1017739, Russ Allbery mentions
>> a(n unrelated) problem which can lead to this:
>> 
>>     % su
>>     # emacs
>> 
>> If the user hasn't yet used Emacs (and depending on the details of which
>> version of `su` you use) this can create
>> a /home/<user>/.emacs.d/eln-cache that's owned by root because we create
>> that dir according to `~$USER` rather than according to `$HOME`.
>
> I didn't mean to say that I didn't understand how this could happen
> _technically_.  What I don't get is how come people let this happen,
> and don't pay attention until Emacs complains?  Isn't it crazy to have
> your home directory unwritable by your user??

I think in the above scenario, if you just upgraded to Emacs-28 and it's
hence the first time you run an Emacs with native compilation, you get
a home directory that's still perfectly writable, including `~/.emacs.d`
and it's only `~/.emacs.d/eln-cache` that's owned by root.

And since Emacs error(s|ed) out right away, the error message didn't let
you find the name of the directories that were searched to figure out
the origin of the problem.


        Stefan