About --download-only option

[amelcon-dot]

Hello,
I am trying to check if the option --download-only could be suitable for me in certain situations.

First, it would be helpful if when using --download-only we get a message pointing out that this option is selected, and therefore
only changes from remote will be synced locally. When using --upload-only we do get a message:

Syncing changes from selected local path only - NOT syncing data changes from OneDrive

However, I could not see a message when using --download-only.

A part from this, I wonder if there is a change in a local file and no changes of this file in remote, will the local file be overwritten by the old remote version (since they are not equal, they end up being equal with remote winning)?. What operations are performed by --download-only?. Files existing in local disk will be erased if they do not exist in remote?.

Finally, it seems that it is very slow to use --download-only. If I normally use bi-sync operations, and then I change and do a --download-only, it seems that it is doing like a --resync and it takes very long time. Is there a way to switch from bi-sync, --download-only and --upload-only and keep it fast?.

Thanks a lot.

[abraunegg]

@amelcon-dot

However, I could not see a message when using --download-only.

Correct, as this mode of operation was in the original 'skilion' client, and no-one before now has asked / queried why there is no message to denote what action is being taken. It could also be argued why --upload-only prints a message .. when - you are manually adding / configuring that method of sync you presumably know exactly what is going on.

This being said, it is trivial to add a message. Will look at that as part of #779 which is in progress.

A part from this, I wonder if there is a change in a local file and no changes of this file in remote, will the local file be overwritten by the old remote version (since they are not equal, they end up being equal with remote winning)?. What operations are performed by --download-only?. Files existing in local disk will be erased if they do not exist in remote?.

This client is a 'sync' client. It replicates the 'state' from a -> b ... so, if you are performing a --download-only operation, if a file has been modified / removed online, then that state will be replicated locally. You can always check what the client will do with --dry-run - this is exactly why this option exists so you can test the client in each of your usage scenarios.

Finally, it seems that it is very slow to use --download-only. If I normally use bi-sync operations, and then I change and do a --download-only, it seems that it is doing like a --resync and it takes very long time. Is there a way to switch from bi-sync, --download-only and --upload-only and keep it fast?.

This should not be the case.

For a normal sync, the process is:

1. Check online, using the /delta path. The caveat here is if you are using --resync, the /delta path is unknown, thus full sync is done
2. Check local DB against all local files in DB, upload new differences - there is no shortcut here
3. Check online, using the /delta path, ensuring local DB is insync with online version

In a --download-only scenario, step 2 & step 3 above are not done

In a --upload-only scenario, only step 2 is performed.

In both instances, it should be relatively quick, and, especially for --download-only use the /delta path .. however, as per #1393 in which you are using 'rclone' + 'onedrive' - if you are still using multiple clients - then the /delta details on one client will be invalid, thus, full scan will be done ... please dont use 2 different clients.

[amelcon-dot]

Yes, thanks for the answer. After your recommendation I stopped using rclone, but the previous use may have caused wrong /delta. I have verified that the first time I run --download-only it does some work updating the DB items.sqlite3. Maybe as you say, trying to update the /delta (to be honest I am not sure what is /delta). In any case subsequent runs are indeed very fast. I have been testing --download-only and I can confirm that local changes are not lost with a copy from remote; they are just ignored. So a file existing only in local disk is not erased. I will have to study if this can be useful for me. In my current work I do either changes in the local drive or the remote is changed, but not at the same time (weekdays local disk is changed, and weekend remote is changed). So, I wonder if it will be safe to do a careful combination of --upload-only and --download-only.
Again, thanks for your help.

[abraunegg]

Yes, thanks for the answer. After your recommendation I stopped using rclone, but the previous use may have caused wrong /delta. I have verified that the first time I run --download-only it does some work updating the DB items.sqlite3. Maybe as you say, trying to update the /delta (to be honest I am not sure what is /delta). In any case subsequent runs are indeed very fast. I have been testing --download-only and I can confirm that local changes are not lost with a copy from remote; they are just ignored. So a file existing only in local disk is not erased. I will have to study if this can be useful for me. In my current work I do either changes in the local drive or the remote is changed, but not at the same time (weekdays local disk is changed, and weekend remote is changed). So, I wonder if it will be safe to do a careful combination of --upload-only and --download-only.
Again, thanks for your help.

OK ... so why are you not just utilising either:

• --monitor
• --synchronize

When using either of these options, local data will be uploaded, remote data will be downloaded - when that data is changed, ensuring that both locations are insync .... so you do not have to worry about doing careful combinations or run the wrong one accidentally. The client makes the applicable checks so that data is not incorrectly overwritten. I have gone to great lengths to ensure data integrity.

If it is a matter of only syncing a single directory (use --single-directory) or if it is a matter of only syncing a certain combination of directories or files use 'sync_list' .. otherwise use 'skip_dir' and 'skip_file' to skip certain types of data.

I really think you are over complicating this for yourself.

Remember - test everything with --dry-run first ... this shows you what would occur, without it actually occurring.

[amelcon-dot]

Hello, yes, this is probably my bad coming from rclone, since there is not bisync capability in that tool.
Somehow I thought that it would be safer for the data to manually guide the directionality of the syncs.
However, if data integrity is ensured, then yes, the best is to use bisync; and the time overhead is not that much.
The --dry-run capability is very good. I have seen that it takes the current state by copying the data base into a temporary data base called items-dryrun.sqlite3; so it actually simulates what would occur in the current state.
So for the moment everything seems fine, thanks for your kind support.