Hi,

On Fri, Sep 21, 2018 at 04:42:37PM -0700, Paul Eggert wrote:
> Johannes Schauer wrote:
> > This problem could be solved by coreutils using the glibc renameat2 function in
> > glibc version 2.28 and newer.
> 
> Yes, that's on my list of things to do. It's not high priority, though, so
> if you want it done faster you can write up and test the code and submit a
> patch (hint, hint).
> 

Probably going to embarras myself here with no prior coreutils (or
gnulib) experience and including an untested patch, but oh well.

I tried to look at this issue and AIUI this is basically a gnulib
issue rather than coreutils. There's even been some relevant changes
done since (the gnulib version included in) coreutils 8.30:
http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=2522322e5304e7d86c63e607e2bc83c8d8b0a889

Since I have no idea how to bundle a new gnulib version with coreutils
to build a test version (and I don't even have glibc 2.28 yet either),
I haven't been able to test but wouldn't a simple patch like the
attached one do the trick?
(Note: stdio.h is already included so no addition for it needed. The
fallback discussed in [1] should be the same for HAVE_RENAMEAT2 and 
SYS_renameat2 codepaths.)

[1] https://sourceware.org/ml/libc-alpha/2018-07/msg00064.html

I assume if it was this simple you'd have already delt with it, so
I'm probably way too naive here.

Regards,
Andreas Henriksson