Hey, I had a lightning strike and lost some hardware. I figured I’d try Insync 3.x as part of a entire rebuild of my desktop system. I’m doing a large restore and have run into Insync stalling on certain files with 12 “Unexpected error doing DownloadGDBlob:” errors piling up under “Attention required” and then all progress ceases.
So I eventually figured out that this was due to some old war web archives and some PUB files I have from an old 1990s era DTP program. Fairly obscure formats. I downloaded and zipped them, and Insync happily downloaded [note 1] the zipfiles. Then I ran into a maze of directories with hundreds. So I used rclone.
Ah, ha! rclone also failed, but it threw a useful error saying:
open file failed: Use the --drive-acknowledge-abuse flag to download this file: googleapi: Error 403: This file has been identified as malware or spam and cannot be downloaded., cannotDownloadAbusiveFile
I added the --drive-acknowledge-abuse
to the rclone command line and everything downloaded just fine. It appears that Insync 3 does not handle this situation at all, and as errors accumulate, all syncing stops as the queue fills up with files it can not process.
I’m on Linux, but it should make no difference as this is a Google API error. I hope that this is of some use to the devteam. Best of luck, and thanks for a great product! I happily upgraded my account from Plus (or whatever I was) to Prime as part of the Insync 3 switchover. Keep the updates coming!
Note 1: I thought the zip archive trick fixed it, but it looks like it just re-queued the files. When they came up for download again, Google had peeked in the archive and declared it a bad file, causing the same problem. Tossing a password on the zips is a functional work-around. And I know the bad file flagging is erroneous, especially for the war files, as I wrote the program that generated those.