bug-gnulib
[Top][All Lists]
Advanced

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

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


From: Florian Weimer
Subject: Re: [PATCH] Add renameat2 function [BZ #17662]
Date: Wed, 4 Jul 2018 12:39:50 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0

On 07/04/2018 11:04 AM, Andreas Schwab wrote:
On Jul 03 2018, Paul Eggert <address@hidden> 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



reply via email to

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