Problems Syncing Root of Google Team Drive

Seeing some weird behavior that I can’t figure out and thought it might be a bug. Maybe it’s just me doing something wrong though - wouldn’t be the first time.

I have 5 main folders at the root of my Google Team Drive. Each is fairly large, from 5000-50000 files and from 20GB-3TB in size. Typically, I monitor for changes to files and only upload new ones. Occasionally, I’ll cross check the Cloud server vs the local servers I have available just to make sure thinks haven’t gotten sideways.

If I run a SYNC command vs the individual folders (which is what I typically do), everything goes fine.

rclone sync REMOTE:FOLDER1 Z:\STORAGE\FOLDER1 = no files transferred, everything checked.

If I try to run a SYNC command vs the overall drive, things go to hell and rclone starts transferring seemingly random files from the remote back to local.

rclone sync REMOTE: Z:\STORAGE = DOWNLOAD TONS OF FILES!l!!ONE1!!

I’ve done a little digging into the -vv and -dry-run flags and I cannot figure out what’s going wrong. Scenario one tells me no change in the size or time, skipping the file. Scenario two tells me it’s not copying since it’s a dry-run.

So, a couple of questions;

  • Is there any reason why the behavior would be different when running rclone on the root folder vs the subfolders?
  • Is there a way to force rclone to provide the reason for copying a file during transfer? As it stands, I can’t tell why it thinks the file needs to be transferred when I run scenario 2.

Thanks!

Alright, went through and ran a dry-run on the root and then on each individual folder, something definitely seems screwy:

ROOT
Checks:             48683
Transferred:         3518

FOLDER1:
Checks:              3483
Transferred:            0

FOLDER2::
Checks:             14003
Transferred:            4

FOLDER3:
Checks:             30358
Transferred:           30

FOLDER4:
Checks:               749
Transferred:            0

FOLDER5:
Checks:                86
Transferred:            0

These were run with the exact same command, just added the folder onto the root. Can someone explain?

Hmm that is strange!

Can you do rclone ls for the root and the individual folders and compare the output?

When you run the sync from the root with -vv can you paste some log showing why rclone did the transfer?

Have run the LS and get identical output from both the root folder and the subfolders. As an aside, the lsf command doesn’t seem to work on the latest version of rclone, comes up as unkown command.

I’ve logged the full sync doing a -vv --dry-run, but it doesn’t give me any information as to WHY it’s syncing the offending files, just says that it’s not copying due to dry-run. Is there a way to get that information without actually running the real sync?

EDIT: Ran a real sync and canceled it out after seeing some data start transferring - The only information given is - “Copied (new)”

A CLUE!

Something is weird with FOLDER1.

Playing around with syncing I came to the realization that EVERY SINGLE ITEM IN FOLDER1 is trying to re-sync. You can look at the numbers above, if you add all the items in FOLDER1 plus the other transferred items, you get the total transferred for ROOT (or close enough).

Here’s another kicker though - I let ROOT sync run for a while, until it had transferred at least a dozen GB+ files, then killed the command. Just out of curiosity, I ran it again and sure enough, it proceeded to immediately redownload those same files.

Further information - running the sync command on a computer that has a mirror of the data does not attempt to transfer the files from FOLDER1, it’s perfectly happy with them.

So that seems to be narrowing it down to something to one computer on my end. Both machines I can access are running Win10 Pro and the data is stored on a Stablebit Drivepool. If you have any suggestions on things I could check I’d appreciate it but I understand this is getting into fringe case territory.

There is a previous issue about rclone with stablebit - not sure it is relevant but there is a suggestion to try there too.