Re: [PATCH] Add renameat2 function [BZ #17662]

On 07/04/2018 04:26 PM, Florian Weimer wrote: > On 07/04/2018 10:13 PM, Carlos O'Donell wrote: >> This is a good suggestion, and I think Florian should work on >> something going into the manual to document the behaviour. > > We do not have any documentation for the *at functions at present. I >

Re: [PATCH] Add renameat2 function [BZ #17662]

Carlos O'Donell wrote: On 07/04/2018 03:35 PM, Paul Eggert wrote: You position Gnulib's implementation as having no drawbacks That certainly was not my intent. The Gnulib implementation has known race conditions on platforms whose kernels don't promise atomicity. It's just that Gnulib-usin

Re: [PATCH] Add renameat2 function [BZ #17662]

Florian Weimer wrote: as Joseph pointed out, there is a different emulation strategy with a different failure mode (use link and potentially leave behind a hard-linked file under both names). So far I haven't run into applications that prefer that strategy, i.e., nobody seems using that strat

Re: [PATCH] Add renameat2 function [BZ #17662]

On 07/04/2018 10:13 PM, Carlos O'Donell wrote: This is a good suggestion, and I think Florian should work on something going into the manual to document the behaviour. We do not have any documentation for the *at functions at present. I find it difficult to document renameat2 without referenc

Re: [PATCH] Add renameat2 function [BZ #17662]

On 07/04/2018 03:35 PM, Paul Eggert wrote: > Carlos O'Donell wrote: > >> If we really need another non-race-free API then gnulib can provide >> that. > > We do really need it. All existing uses of renameat2-like > functionality in GNU applications already use the non-race-free API. > But as I see

Re: [PATCH] Add renameat2 function [BZ #17662]

Carlos O'Donell wrote: If we really need another non-race-free API then gnulib can provide that. We do really need it. All existing uses of renameat2-like functionality in GNU applications already use the non-race-free API. But as I see it, the consensus is to banish this functionality to Gn

Re: [PATCH] Add renameat2 function [BZ #17662]

On 07/04/2018 05:04 AM, Andreas Schwab wrote: > On Jul 03 2018, Paul Eggert wrote: > >> Florian Weimer wrote: >>> Surely that's a gnulib bug because the main reason for the >>> RENAME_NOREPLACE variant renameat2 was to avoid exactly that race (or >>> the other race where the file exists under bot

Re: [PATCH] Add renameat2 function [BZ #17662]

On 07/04/2018 11:04 AM, Andreas Schwab wrote: On Jul 03 2018, Paul Eggert wrote: Florian Weimer wrote: Surely that's a gnulib bug because the main reason for the RENAME_NOREPLACE variant renameat2 was to avoid exactly that race (or the other race where the file exists under both the old and n

Re: [PATCH] Add renameat2 function [BZ #17662]

On Jul 03 2018, Paul Eggert wrote: > Florian Weimer wrote: >> Surely that's a gnulib bug because the main reason for the >> RENAME_NOREPLACE variant renameat2 was to avoid exactly that race (or >> the other race where the file exists under both the old and new path). > > No, it's intended behavio

Re: [PATCH] Add renameat2 function [BZ #17662]

Florian Weimer wrote: Surely that's a gnulib bug because the main reason for the RENAME_NOREPLACE variant renameat2 was to avoid exactly that race (or the other race where the file exists under both the old and new path). No, it's intended behavior, not a bug. GNU mv uses renameat2 with RENAM

Re: [PATCH] Add renameat2 function [BZ #17662]

On 07/02/2018 07:38 PM, Paul Eggert wrote: Florian Weimer wrote: Without kernel support, a non-zero argument returns EINVAL, not ENOSYS. This mirrors what the kernel does for invalid renameat2 flags. The Gnulib renameat2 function

Re: [PATCH] Add renameat2 function [BZ #17662]

Joseph Myers wrote: We've had complaints in glibc about fallbacks that introduce races (e.g. for pselect). Do you have reason to believe that this race is somehow different and introducing it will never cause problems for users? "Never" i

Re: [PATCH] Add renameat2 function [BZ #17662]

On Mon, 2 Jul 2018, Paul Eggert wrote: > The Gnulib renameat2 function > has > different semantics with non-zero flags. On GNU/Linux if > flags==RENAME_NOREPLACE and the Linux syscall fails due to > EINVAL/ENOSYS/ENOTSUP, Gnulib r

Re: [PATCH] Add renameat2 function [BZ #17662]

Florian Weimer wrote: Without kernel support, a non-zero argument returns EINVAL, not ENOSYS. This mirrors what the kernel does for invalid renameat2 flags. The Gnulib renameat2 function has different semantics with non-zero