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

[Lars Ingebrigtsen <larsi@gnus.org>]

Philipp Stephani <p.stephani2@gmail.com> writes:

> 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.

Hm, interesting...

>> > 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.

No, I can't think of any cases where this would lead to a worse result
than the current situation, but it's somewhat scary making a low-level
general change like this in `rename-file' -- I have no idea whether
EBUSY is used for other oddball failure cases like this.

Making the change in byte-compile-file sounds safer, but would require
more work.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no