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

2018-10-29 Thread Assaf Gordon
tags 32796 fixed close 32796 stop On 2018-10-08 12:27 a.m., Paul Eggert wrote: Thanks for checking. I installed the attached into Gnulib master. The "(tiny change)" is because the patch is small enough that we don't need to worry about copyright papers. Pushed here:

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

2018-10-08 Thread Paul Eggert
Thanks for checking. I installed the attached into Gnulib master. The "(tiny change)" is because the patch is small enough that we don't need to worry about copyright papers. >From c50cf67bd7ff70525f3cb4074f0d9cc1f5c6cf9c Mon Sep 17 00:00:00 2001 From: Andreas Henriksson Date: Sun, 7 Oct 2018

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

2018-10-07 Thread Johannes Schauer
Quoting Paul Eggert (2018-10-07 22:21:12) > The strace results you sent were of the old code and the new code, apparently > running in a chrooted environment. I'd like to see what happens if the test > is run in a non-chrooted environment; just the basic environment that people > get when they log

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

2018-10-07 Thread Paul Eggert
Johannes Schauer wrote: Which test result would you like to see? I have coreutils with that patch running on my system and in the chroot and mv seems to be working fine as far as I can see. The strace results you sent were of the old code and the new code, apparently running in a chrooted

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

2018-10-07 Thread Paul Eggert
Johannes Schauer wrote: Which other tests should I perform? I'd like to see a test using glibc without a fake root, as that's the most common way this code will be used.

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

2018-10-07 Thread Johannes Schauer
Quoting Paul Eggert (2018-10-07 22:14:11) > Johannes Schauer wrote: > > Which other tests should I perform? > I'd like to see a test using glibc without a fake root, as that's the most > common way this code will be used. Which test result would you like to see? I have coreutils with that patch

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

2018-10-07 Thread Johannes Schauer
My last mail seems to have been dropped. Maybe because of the attachment size? I now gzipped the attachments. Hi, Quoting Paul Eggert (2018-10-07 02:54:09) > Andreas Henriksson wrote: > > wouldn't a simple patch like the attached one do the trick? > Most likely yes, but I'd like it tested before

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

2018-10-06 Thread Paul Eggert
Andreas Henriksson wrote: wouldn't a simple patch like the attached one do the trick? Most likely yes, but I'd like it tested before installing. This is because the patch shouldn't affect behavior on any platform, and it's better to sanity-check a clerical patch like this (by actually using

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

2018-10-06 Thread Andreas Henriksson
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 >

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

2018-09-21 Thread Johannes Schauer
Hi, tools like `mv` currently perform a direct renameat2 syscall. This is problematic for software like fakechroot which allows one to perform a fake chroot call without being root by intercepting and overriding libc functions using LD_PRELOAD. It is currently not possible to perform a `mv` with