[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#32796: please consider using renameat2 from glibc if available

From: Andreas Henriksson
Subject: bug#32796: please consider using renameat2 from glibc if available
Date: Sat, 6 Oct 2018 20:40:56 +0200
User-agent: NeoMutt/20170113 (1.7.2)


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:

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.

Andreas Henriksson

Attachment: 0001-renameatu-Use-renameat2-when-available.patch
Description: Text Data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]