I am using windows and linux in the same notebook, with dual boot, I would like to know if it is possible to synchronize both windows and linux in the same folder for example:
Windows K:\odrive
and
Linux /driveK/odrive
???
Hi @candido1212,
This is a good question. This is not a scenario we have tested, but I foresee that you could run into some issues in doing this.
You will end up having two different engines with different local caches for tracking the files. I think the sync engine can resolve most changes well enough, in theory, but there may be some scenarios that could cause some trouble. For example, using Encryptor folders would probably end up uploading every new file twice (once on each OS). The OS’s will also have different constraints for allowed characters, reserved words, etc, which can create some oddities with how each instance of the odrive sync engine syncs the content.
It may be okay, depending on your use case and how you use odrive, but it’s not something I can recommend.
thanks for the reply, I imagined that it would not even work, even indicating the same sync index folder.
1 Like
Wouldn’t it be the case that the machine will either be booted into Windows or into Linux at any one time, so the sync will happen with the Windows client if you are running Windows and the Linux client if you are running Linux; in each case it will be the only sync process running. So would there be a problem? Be careful with file names to avoid problems with reserved characters.
Hi @bmff.engagement,
In this case the issue isn’t having two sync engines act on the same data at the same time (which has a larger potential for issues). The issue in the above case deals with two engines persisting information about the same local local files/folders.
odrive keeps a persisted cache of the state of the system so that it can tell what has been changed if the sync engine has been turned off for a period of time, for example. What will end up happening in this scenario is that one sync engine will have already dealt with the changes on the local system. When the other engine comes online it will see new local changes, from its perspective. In many cases this can work out as a no-op because it will also see that there was a remote change and can correlate that. Encryption throws a wrench in the works here, though, because the remote, encrypted content is always different than the local, unencrypted content. The engine that uploaded the file understands this when it deals with the local content and can keep that correlation, but the engine that did not do the uploading thinks it needs to upload again.
Another case: If you were to unsync a folder in one engine and then switch to the 2nd engine, the 2nd engine is unaware of the unsync process (it thinks that a folder should be here right now). It sees a placeholder file that it did not create and considers it invalid. This can lead the the 2nd engine thinking that the folder has actually been locally deleted, instead of unsynced with a different engine.
There are probably more scenarios like this, but suffice to say these are not scenarios we test and I can see that there may be issues, depending on how you use odrive.