[Top][All Lists]

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

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

From: Joseph Myers
Subject: Re: [PATCH] Add renameat2 function [BZ #17662]
Date: Mon, 2 Jul 2018 19:46:24 +0000
User-agent: Alpine 2.20 (DEB 67 2015-01-07)

On Mon, 2 Jul 2018, Paul Eggert wrote:

> The Gnulib renameat2 function
> <https://www.gnu.org/software/gnulib/MODULES.html#module=renameat2> 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 renameat2 falls back on fstatatting the
> destination, failing if fstatat succeeds, and using ordinary renameat
> otherwise. Of course this implementation has a race condition, but
> Gnulib-using applications like GNU 'mv' prefer this implementation since if
> the kernel doesn't support RENAME_NOREPLACE they'd just fall back on fstatat
> themselves anyway, if renameat2 didn't do that for them.

We've had complaints in glibc about fallbacks that introduce races (e.g. 
<https://sourceware.org/bugzilla/show_bug.cgi?id=9813> for pselect).  Do 
you have reason to believe that this race is somehow different and 
introducing it will never cause problems for users?

There are other possible fallbacks an application could try depending on 
the files it's trying to rename and what failure conditions it wants to 
allow for - for example, a linkat/unlinkat pair, when renaming a 
non-directory that's not at the maximum link count, would also guarantee 
not to replace an existing destination, at the risk of leaving two links 
if the source directory is read-only, the destination directory is 
writable, and the destination directory is made read-only during the 
renameat2 execution before it tries to remove the destination link after 
removing the source link failed.

Joseph S. Myers

reply via email to

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