bug#44631: 28.0.50; Byte compilation fails if destination file is a mount point

[Philipp Stephani]

Am Sa., 14. Nov. 2020 um 17:04 Uhr schrieb Lars Ingebrigtsen <larsi@gnus.org>:
>
> Philipp Stephani <p.stephani2@gmail.com> writes:
>
> > Granted, this is rather exotic.
>
> It's really exotic.  :-)  I'm just wondering -- did you happen upon this
> while trying to do something, or is it just designed to trigger the bug?

I've been experimenting with creating a sandbox for Emacs using
https://developers.google.com/sandboxed-api/. That works by (a)
installing a Linux kernel syscall filter to limit the allowed
syscalls, and (b) enabling user and mount namespaces. Using the mount
namespaces, the sandbox can be restricted exactly to the files that
Emacs needs to access. In the case of byte compilation, it needs to
write exactly one file, the byte-compiled output, so it's possible to
mount exactly that file. This bug makes this approach impossible.
(That's not a really onerous restriction; one can e.g. mount an empty
directory, and then have the output file written there. It would just
be nicer if it worked without such workarounds.)

>
> > Nevertheless, byte-compile-file could
> > fall back to a direct write-region without temporary file + rename, or
> > rename-file could fall back to copy + remove on EBUSY (like EXDEV).
>
> Hm...  the latter sounds like an easy fix, but aren't there more commond
> cases where you get EBUSY where copy + remove would fail, too?

Probably, but I guess the situation wouldn't become worse, as
presumably these cases already fail today.