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

[Philipp Stephani <p.stephani2@gmail.com>]

Am Di., 24. Nov. 2020 um 07:16 Uhr schrieb Lars Ingebrigtsen <larsi@gnus.org>:

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

I guess it also depends on what the semantics are that
byte-compile-file guarantees. If it attempts to guarantee atomicity,
then only a intra-filesystem rename (or similar alternatives such as
O_TMPFILE + linkat) are acceptable, and technically, not even the
current fallback on EXDEV (which makes rename-file nonatomic) is OK.
If atomic writes are best-effort, then we could always fall back to
copy-file + delete-file on any file-error.