|
From: | John Stanley |
Subject: | bug#32393: coreutils-8.30 'mv' error for file on libfuse mounted shares |
Date: | Wed, 8 Aug 2018 04:21:11 -0400 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.4 |
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
Description: Text document
[Prev in Thread] | Current Thread | [Next in Thread] |