On Jul 03 2018, Paul Eggert <egg...@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. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
