Any operation on a personal onedrive account (ls, copy, touch) takes about 30-45 seconds to complete. I'm trying to find out if this is to be expected, or a problem at my end I need to investigate, as the latency makes it unusable for my purposes.
What is your rclone version (output from rclone version)
rclone v1.55.1
Which OS you are using and how many bits (eg Windows 7, 64 bit)
os/type: linux
os/arch: amd64
Which cloud storage system are you using? (eg Google Drive)
Onedrive
The command you were trying to run (eg rclone copy /tmp remote:tmp)
rclone touch onedr:/xx
The rclone config contents with secrets removed.
Paste config here
A log from the command with the -vv flag
2021/04/29 02:06:00 DEBUG : Using config file from "/home/user/.config/rclone/rclone.conf"
2021/04/29 02:06:00 DEBUG : rclone: Version "v1.55.1" starting with parameters ["rclone" "-vv" "touch" "onedr:/xx"]
2021/04/29 02:06:00 DEBUG : Creating backend with remote "onedr:/"
2021/04/29 02:06:00 DEBUG : Creating backend with remote "__raw_onedrive_mine:rcroot/onedr"
2021/04/29 02:06:21 DEBUG : r7jib0qa941rdarg01rilps8ao: Starting multipart upload
2021/04/29 02:06:26 DEBUG : r7jib0qa941rdarg01rilps8ao: Uploading segment 0/32 size 32
2021/04/29 02:06:32 DEBUG : xx: SHA-1 = 9ec3d3faa454e3dbcfe9c5b14f2dd416f15786f2 OK
2021/04/29 02:06:32 DEBUG : 6 go routines active
@Ole, thank you for the response! I tried the --dump 'requests', and that showed me that what was happening is completely unrelated to rclone. It was a DNS issue at my end that was causing the 30+ second latency! I hadn't noticed or thought of it because I generally use the terminal only to connect to hosts within a corporate network, which don't suffer from these long latencies.
Thank you again for the help, and apologies I hadn't checked this first!
For others hitting similar issues, even though this is unrelated to rclone: I'm running Ubuntu/x86_64 via WSL2. Doing:
nslookup onedrive.com
took several seconds, which was because my first nameserver did not resolve, and the backup nameserver eventually did. In my case, the solution was to set /etc/resolve.conf to be auto-generated.
There is also a "third party" solution which I've had success with. Instead of fighting with the Hyper-V virtual networking that WSL uses, it uses Docker's approach: Using components from Docker Desktop for Windows to create a network adapter in the wsl distro that connects to the host via a process pipe, where the traffic is "routed" directly to the hosts network connection. Then the wsl distro will use any vpn and whatever dns settings etc that the host uses.