Already did..should've included it. It's not particularly revealing to 
me though (I've attached the trace). The syscall goes as:

renameat2(AT_FDCWD, "/home/john/mnt/sshfs/status-20180806", AT_FDCWD, 
"/home/john/mnt/sshfs/status-20180807", RENAME_NOREPLACE) = -1 ERANGE 
(Numerical result out of range)

Also, I've run some a quick 'n dirty code to simply do the rename 
syscall which gives the same result.
But, if in this code I simply invoke glibc's  renameat() (which is 
renameat2() less the "flags" arg), I do not get any errors.  So perhaps 
the issue is related to the RENAME_NOREPLACE flag. In fact, with my test 
code, if I do the syscall renameat2 with flags = 0, then also no error.

Note that in my test cases the source and destinations are regular files 
and the destination does not exist. If the destination does exist, then 
I get a different error:

  mv  ~/mnt/sshfs/status-20180806 ~/mnt/sshfs/status-20180807
error: 17 File exists

which, of course, does not occur for "local" files.



Paul Eggert wrote:
> John Stanley wrote:
>> I'm wondering if anyone intimately familiar with the SYS_renameat2 
>> rework in coreutils-8.30 'mv' might have any ideas on how to pin this 
>> one done.
>
> Sure, run this:
>
> strace mv ~/mnt/sshfs/status-2018080{6,7}
>
> and look at the strace output.
>