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: Paul Eggert
Subject: Re: [PATCH] Add renameat2 function [BZ #17662]
Date: Mon, 2 Jul 2018 10:38:22 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0

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 
<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.
It strikes me that this will be a common use case for RENAME_NOREPLACE in other 
glibc applications too, perhaps the most common one. In that case, perhaps glibc 
should support the Gnulib semantics, by falling back on a non-atomic 
implementation of RENAME_NOREPLACE if the kernel doesn't support the atomic one. 
If that's too drastic, how about having glibc support a new flag 
RENAME_NOREPLACE_NONATOMIC that works on all platforms? We could of course add 
such a flag to Gnulib, but I expect it'd be better if the functionality were 
available to all Glibc programs, not just to Gnulib-using programs.
PS. In Gnulib-using apps we've found no need for RENAME_EXCHANGE or 
RENAME_WHITEOUT and so Gnulib does not implement them on older GNU/Linux 
kernels. Gnulib renameat2 does support RENAME_EXCHANGE on macOS since it's easy 
there.
[CC:ing this to bug-gnulib; for those joining in, a recent email in this thread 
is here:
https://sourceware.org/ml/libc-alpha/2018-07/msg00003.html

]



reply via email to

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