I'm using Local Google Drive (Mounted at G:). I've fewcrypt creates that encrypt contents before pushing it to My Drive and Shared Drive. The Google Drive preferences are to stream files.
Problem is I get a cache failed error
vfs cache: failed to upload try #5, will retry in 2m40s: vfs cache: failed to transfer file from cache to remote: corrupted on transfer: md5 crypted hash differ "45454fa05ef77ba7e25e897fd4347742" vs "c98cebe007f9f4897fc199f989d8769b"
I think the issue is the files gets deleted as soon as it is uploaded and the checksum fails.
Any inputs on resolving this
-- Disabling cache verification
--etc
What is your rclone version (output from rclone version)
Using a beta version with only a specific fix for unions
- os/version: Microsoft Windows 10 Pro 2009 (64 bit)
- os/kernel: 10.0.22000.376 (x86_64)
- os/type: windows
- os/arch: amd64
- go/version: go1.17.1
- go/linking: dynamic
- go/tags: cmount
Which cloud storage system are you using? (eg Google Drive)
Google Drive locally mounted on G: with official drive application
The command you were trying to run (eg rclone copy /tmp remote:tmp)
favicon.ico seems to be on the only file having the error failed to transfer file from cache to remote: corrupted on transfer: md5 crypted hash differ
so is that a one time error, or something that is happening all the time?
if you are using a union, did not see it in the config file, are you creating it on the fly? rc: "mount/mount": with parameters map[fs:gc:
in that log, desktop.ini is in the local crypt remote and should not be there.
only files with crypted names should be there.
looks like windows is adding that file, as it like to do so.
and a side-question,
why use the G: drive using google drive software instead of using rclone?
make use of flags such as --drive-server-side-across-configs
favicon.ico seems to be on the only file having the error
failed to transfer file from cache to remote: corrupted on transfer: md5 crypted hash differ
so is that a one time error, or something that is happening all the time?
No all files have the error all the time.
if you are using a union, did not see it in the config file, are you creating it on the fly?
rc: "mount/mount": with parameters map[fs:gc:
It's there, some lines from my first post are not appearing. Here they go again.I had tried to mask few things earlier. Posting it again, to go along with debug logs
[g0]
type = crypt
remote = G:\My drive\np
filename_encryption = standard
directory_name_encryption = true
password =
password2 =
[g1]
type = crypt
remote = G:\Shared drives\Limitless\np
filename_encryption = standard
directory_name_encryption = true
password =
password2 =
[gc]
type = union
upstreams = g0: g1:
in that log, desktop.ini is in the local crypt remote and should not be there.
only files with crypted names should be there.
looks like windows is adding that file, as it like to do so.
Yes, added by Windows. I'll try removing to see if it helps, but I did see that it was skipped and error is being called out explictly for the file. So, unlikely that removing it will help.
Edit: Error continues even after removing the desktop.ini file
and a side-question,
why use the G: drive using google drive software instead of using rclone?
make use of flags such as --drive-server-side-across-configs
I see a heavy lag when trying to mount the drives directly instead of using local G: and the uploads were painfully slow due to various limitations imposed. I didn't see errors though. I din't use --drive-server-side-across-configs though. Also, I am not primarily copying server to server. Though I see it would help during renames and movements as well and will try using it.
I guess your beta was compiled in your own development environment and contains your beta fix for this:
Have you ruled out the possibility of issues in your own code or development environment by reproducing with the official 1.57.0 binary? That is the binary downloaded from here: https://rclone.org/downloads/
PS: I recommend purging the mount cache before you test on the official binary, just to eliminate any possibility of data issues stemming from your own development.
What's the reason to use the Google Client over rclone? There are features that make rclone work better with rclone on a crypt since it's all the same package. You are doubling up with Google's client causing potential issues with rclone so I'm not sure why the choice was made to use that.
rclone v1.57.0
- os/version: Microsoft Windows 10 Pro 2009 (64 bit)
- os/kernel: 10.0.22000.376 (x86_64)
- os/type: windows
- os/arch: amd64
- go/version: go1.17.2
- go/linking: dynamic
- go/tags: cmount
Google drive mounted directly is very slow for me and hence I opted for client. I think I'll need to retry some options to improve this.
BTW, I use similar setup for OneDrive, Dropbox and Pcloud and they aren't problematic. I think its optimistic streaming which is causing the problem. If I disable it, it would most likely work - but it would make a local copy of everything which I don't want it do.
Mounting the cloud providers directly is slow across providers. I don't see it on dropbox and onedrive as they are almost entirely synched to local disk.
I can only guess for Drive. Drive app may not be having any API restrictions or some forward caching algorithms.