GNU bug report logs -
#44631
28.0.50; Byte compilation fails if destination file is a mount point
Previous Next
Reported by: Philipp Stephani <p.stephani2 <at> gmail.com>
Date: Sat, 14 Nov 2020 12:41:02 UTC
Severity: normal
Found in version 28.0.50
Done: Philipp Stephani <p.stephani2 <at> gmail.com>
Bug is archived. No further changes may be made.
Full log
Message #11 received at 44631 <at> debbugs.gnu.org (full text, mbox):
Am Sa., 14. Nov. 2020 um 17:04 Uhr schrieb Lars Ingebrigtsen <larsi <at> gnus.org>:
>
> Philipp Stephani <p.stephani2 <at> 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.
This bug report was last modified 4 years and 161 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.