On 02/03/2024 23:18, Petr Malat wrote:
On Sat, Mar 02, 2024 at 01:59:31PM +0000, P??draig Brady wrote:
On 02/03/2024 12:46, Dominique Martinet wrote:
Thanks for remembering me; didn't try the patch yet but overall looks
good to me.
Just one nitpick on the not supported message check:
P??draig Brady wrote on Sat, Mar 02, 2024 at 11:01:42AM +0000:
+ if (renameatu (AT_FDCWD, file[0], AT_FDCWD, file[1],
+ RENAME_EXCHANGE))
+ {
+ if (errno == EINVAL || is_ENOTSUP (errno))
checking the man page, renameeat with RENAME_EXCHANGE on a dir and
something inside it also fails with EINVAL, so that will print the
operation isn't supported when it can probably be considered a user
error (I did't take the time to try this patch, using another tool to
illustrate but it should be the same):
$ mkdir a
$ touch a/b
$ ./renameat2 --exchange a a/b
renameat2: Invalid argument
For comparison, mv now does:
$ mv -x a a/b
mv: atomic swap of 'a' and 'a/b' is not supported
I guess there's not much we can do about this though, EINVAL could also
really mean not supported in this case and checking if one path is a
prefix of another seems overkill to me...
Right. Since the syscall doesn't distinguish errors in this case,
our error is no better or worse I think. Having mv distinguish
based on path processing would be overkill I agree.
Also it's a bit of an edge case anyway.
We could call renameat2 with both arguments targeting the first file.
If it's supported, it's no-op, but if it's not supported, it returns
an error. Or some common file cold be used, e.g. /dev/null.
Petr
Oh right clever!
I still think it's overkill for this edge case though.
I've augmented the test a little more and pushed.
thanks!
Pádraig
