Bug report for build .282

What is the problem you are having with rclone?

With the latest beta .282, there is something wrong with the RC command. After I start my usual mount, I run "rclone rc vfs/refresh recursive=true --fast-list -v" to prime the content. It now comes back with the following:

"Failed to rc: connection failed: Post "http://localhost:5572/vfs/refresh": net/http: timeout awaiting response headers"

The normal response is:

"{
"result": {
"": "OK"
}
}"

Tried three times in a row to make sure it wasn't a one-off. Went back to .281, and everything is OK.

Didn't have time to get a debug log. Might be able to later, if necessary.

What is your rclone version (output from rclone version)

v1.52.2-282-gf5439ddc-beta

Which OS you are using and how many bits (eg Windows 7, 64 bit)

Windows Server 2016 64-bit

Which cloud storage system are you using? (eg Google Drive)

Google Drive

The command you were trying to run (eg rclone copy /tmp remote:tmp)

rclone mount --attr-timeout 1000h --dir-cache-time 1000h --poll-interval 0 --rc --read-only -v
rclone rc vfs/refresh recursive=true --fast-list -v

The rclone config contents with secrets removed.

[Google_Drive]
type = drive
client_id =
client_secret =
token =
root_folder_id =

[Google_Drive_Crypt]
type = crypt
remote = Google_Drive:crypt
filename_encryption = standard
directory_name_encryption = true
password =
password2 =

A log from the command with the -vv flag

n/a

1 Like

Since there was only one commit in between, it has to have something to do with this:

accounting: fix deadlock in stats printing

1 Like

I am using the same build on Linux and haven't faced this issue.

I suspect that your query is just on the edge of timing out - I think the timeout is 1 minute - how long does it normally take?

You can increase the timeout with --timeout 10m to see if that helps.

You can also run

rclone rc vfs/refresh recursive=true _async=true -v

Then rclone will run the query in the background without waiting for the reply

1 Like

Thanks Nick! Running with "_async=true" did the trick, but I will also try with "--timeout 10m" instead, because I like to actually see when it's done. One thing I noticed is that with async, the whole process seems to complete quite a bit faster. Could be placebo, though, since I didn't measure it.

To answer your question, priming usually takes between a minute and a half to two minutes. One thing that's always bugged me a bit is that I can't see the progress, even though I use -v. Would adding another v show what it's doing? Also, is --fastlist used by default, so it's not necessary to use the flag?

1 Like

That makes sense.

Neither -v or --fast-list have any effect when using the rc command. There isn't a way of getting progress out of the rc at the moment.

1 Like

Just tried it with "--timeout 10m", and it also works great. Thanks again!

(this is with .285, btw)

2 Likes

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.