Errors when syncing Google Drive -> Onedrive with --backup-dir

Help and Support
21

Ok, it worked:

Transferred:   	         0 / 0 Bytes, -, 0 Bits/s, ETA -
Checks:            158244 / 158244, 100%
Deleted:            10184 (files), 456 (dirs)
Renamed:            10133

Total size: 33.515 GBytes

have been moved to --backup-dir folder.

Practically all unrelated to the two folders above...

What scares me is the fact that these 2 problems above (dedupe and owner) in 2 specific folders with just a few files have prevented the --backup-dir option from working correctly in all other folders...

I just realized that this happened - no move to backup-dir - because the affected folders were in the root folder, if they were "deep" folders I would never have noticed. I would probably only notice when the size difference increased and even then it would be difficult to identify the affected folders.

Rclone could even throw errors and not sync these two folders, but affect all other folders?

IMHO, this is not correct, but...

Thank you both for the support.

22

It all depends as once you start deleting things, what might be ok for you might not be for others. I rather not delete unless I am in a consistent state before hand. As @calisro suggested, you can always ignore errors and let it do its thing.

23

But my point here is not about ignore errors or not.

When I perform an operation and a file is not - for example - copied because it was open, I get a message at the end:

"1 file not copied due to access problems" (or something similar)

But the command works for all other files! I only have to solve the problem of that one file.

In this case here I might get an error message at the end, but sync should work for all the other +20,000 files...

24

That's an error, no?

So you have to pick to either ignore it and fix it before sync works as it's deleting things and if there is an error state, it doesn't delete.

In an over simplified example, that could be the case but a sync routine is complex and where/how it errors matters. It isn't quite as simple to just say make it work for this but not that as it gets complex. Best way to is to ensure the source is clean and you copy a clean source to a destination.

I'm sure @ncw can chime in on the complexity of your question albeit from a not programmer like me, I agree it feels easy but programmatically, not so much.

25

I think I still haven't managed to clarify my point.

Real example: a sync run where the following error occurred:

ERROR : [file name]: Failed to copy: can't copy - source file is being updated (size changed from 0 to 27784)

Despite the above error related to a single file, execution worked for all other files...

But in the case reported here in this topic, the google-@#$!%-errors related to a few files prevented all other files from being synced correctly. See the difference? Would it be a peculiarity of I/O type errors?

26

Sorry as I get your point but I do not agree with it (which is fine).

To delete, the first part has to work and that's currently how rclone does it as losing files feels worse imo.

You aren't wrong btw it's just a different perspective so there isn't a point to debate your perspective as it's 100% right for you.

I'm just sharing mine and how rclone works.

27

hi, i think you can use this flag to work around that specifc error.

--local-no-check-updated
28

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