I’m using odrive on a BootCamp system with Win10 and MacOS. The files are stored on an exFat partition both operating systems have access to.
As soon as I switch the operating system to the other and odrive starts scanning, the following happens:
Most files that have been changed on the other operating system are now re-uploaded (at least it’s my impression that it’s primarily new files that are re-uploaded).
Several files are now creating conflicts and thus many (conflict) duplicates, that are exactly the same, are re-uploaded to the cloud.
But not all of the re-uploaded files give a conflict. Some are just overwritten and get a new timestamp, leading to other parties on that cloud drive to need to re-download them.
Sometimes, and I’m not really sure why, older files that I think should have been untouched are uploaded as (conflict) duplicates as well.
All of these duplicates are real duplicates: Same date, same size, same content.
I couldn’t real see what’s the reason for specific files to give a conflict while others are just re-uploaded and overwritten.
The only workaround I’m using so far are two shell scripts that run in parallel to odrive erasing all (conflicts) as soon as they’re created and empty the trash of odrive manually once in a while. My clients are not happy as well, as odrive starts to upload conflicting files into their folders without any reason.
I think what you are describing may be expected with the way that odrive is detecting local and remote changes. I’ll dig into this a bit, but can you tell me what storage you are using with odrive?
Thanks for taking a look! At the moment, it’s Dropbox, Box, Onedrive, some WebDAVs, Amazon and Google Drive. The main issues currently happen with Dropbox, but that might only be because that’s where’s the most changes.
The two systems (Windows 10 and MacOS) have their own odrive tracking information. odrive uses this tracking information to determine what has changed on the local and remote sides. This means that when you update a file on one system, it will change the local and remote information. When you boot into the other system, odrive sees that both the local and remote files have changed since it last looked. This becomes a “conflict” scenario.
I am going to look at the possibility of adding a check to this to ignore the conflict if the remote and local sizes and times are the same. This isn’t taken into account right now because we use unique markers for many integrations, like Dropbox, to determine content changes (like a hash value). If the value changes we assume that a change happened that we need to account for and we don’t look at the “less deterministic” factors, like size and date.
Dropbox may need another couple of tweaks, as well, but I will see what can be done.
Let me know if you get a chance to try it and how it goes. If we are still seeing conflicts we also added more verbose logging to the sync activity log, which will help us to determine if there is something else we can do.
