This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On 07/04/2018 11:04 AM, Andreas Schwab wrote:
On Jul 03 2018, Paul Eggert <eggert@cs.ucla.edu> 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 behavior, not a bug. GNU mv uses renameat2 with
RENAME_NOREPLACE. mv wants the noreplace semantics on platforms that
support it (currently only recent Linux and macOS kernels); otherwise it
wants exactly that race because that's the best that can be done on other
platforms. If Gnulib renameat2 simply failed with EINVAL because
RENAME_NOREPLACE was not supported, GNU mv would simply use the same racy
fallback that Gnulib renameat2 already uses.

Other GNU applications are similar to GNU mv in this respect.

IMHO we should not repeat the pselect error.  Glibc should provide the
race-free guarantee that RENAME_NOREPLACE gives, so that programs that
need it can use it without fear.

What do you think about the rest of the patch? Do you think it can be committed?

Thanks,
Florian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]