GNU bug report logs - #32393
coreutils-8.30 'mv' error for file on libfuse mounted shares

Previous Next

Full log

View this message in rfc822 format

From: John Stanley <jpsinthemix <at> verizon.net>
To: Paul Eggert <eggert <at> cs.ucla.edu>, 32393 <at> debbugs.gnu.org
Subject: bug#32393: coreutils-8.30 'mv' error for file on libfuse mounted shares
Date: Wed, 8 Aug 2018 04:21:11 -0400

[Message part 1 (text/plain, inline)]

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.
>

[mv.mtrace (text/plain, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.