Feature Request: Allow to make remote identical to local regardless of the fact that the client has lost memory of what is in sync

[idohlp2-spec]

Is your feature request related to a problem? Please describe.

I am trying to use 'onedrive' to backup my local data. I expect it to upload files to the remote, or, if they where deleted locally, remove them from the remote. This should be done without requiring a continuous monitoring of the local machine.

Describe the solution you'd like

I request to add a suitable configuration/command line flag that will allow users to make the remote identical to the local data, regardless of the fact that the client has lost memory of what is in sync.

Describe alternatives you've considered

I tried to use:
onedrive --local-first --upload-only --syncdir /root_folder/ --single-directory ./folderA/ --sync

Upload works fine. But local deletes are not applied to the remote.

Additional context

This request follows the discussion in:
#1496

[gabbiani]

I've been struggling with the same issue.

I think the fundamental problem is we are attempting to use OneDrive differently than it's intended use. I've been through so many resets and resync trying to force this to work the way I want. For now I'm going back to my much slower rclone process because I just can't reliably get the client to function how I want. I will watch for future updates and maybe try again.

My desired use case would be local is always the source of truth. The advantage of the client would be greatly reducing processing time by not doing hundreds of thousands of file comparisons like my current process does for a push.

[abraunegg]

@gabbiani

My desired use case would be local is always the source of truth.

This is where --local-first is required - that is available today.

The advantage of the client would be greatly reducing processing time by not doing hundreds of thousands of file comparisons like my current process does for a push.

This is exactly what --upload-only does today - it does not scan anything online.

This feature request is about deleting content online forcefully, making the online state an exact replica of the local state when not using --monitor

To give you further insight to Microsoft Graph API, please read: https://github.com/abraunegg/onedrive/blob/master/docs/server-side-filtering-limitations.md

[gabbiani]

That doesn't match my experience though. My config has upload_only = "true" but it continued to make changes to my local files when timestamps didn't match. I set my local mount (not the DB) to read-only and the client throws errors because it can't make changes to my local files.

I had wrongly assumed --local-first and --upload-only would also delete. So I'll stay subscribed to this.

[abraunegg]

@gabbiani

That doesn't match my experience though. My config has upload_only = "true" but it continued to make changes to my local files when timestamps didn't match. I set my local mount (not the DB) to read-only and the client throws errors because it can't make changes to my local files.

That sounds like you are hitting a bug that was fixed a LONG time ago .. what client version are you running?

99% of the issues that folk run into - are bugs due to old client versions .. it is very rare for regression bug.

[gabbiani]

onedrive v2.5.10-1+np1+1.2
cat /etc/apt/sources.list.d/onedrive.list
deb [arch=amd64 signed-by=/usr/share/keyrings/obs-onedrive.gpg] https://download.opensuse.org/repositories/home:/npreining:/debian-ubuntu-onedrive/Debian_13/ ./

With --local-first and --upload-only why is the client trying to modify local timestamps?

ERROR: The local file system returned an error with the following details:
Calling Function: util.setLocalPathTimestamp()
Path: TN/Data_Encrypted/Backups/path....
Error Message: TN/Data_Encrypted/Backups/path....: Read-only file system
NOTE: This error requires attention; the client may continue running, but functionality is impaired and the issue should be resolved.

Thank you for the responses. Sorry for hijacking the request.

[abraunegg]

@gabbiani

onedrive v2.5.10-1+np1+1.2

my recommendation then is you open a new issue ticket and provide a debug log via email for your timestamp item.

1. when using 'local first' and 'upload only' the local file timestamps will be used
2. when the file is uploaded, Microsoft, depending on the upload method, changes the timestamps
3. the JSON response that is provided back to client (with the OneDrive timestamp) is what is stored in the database .. recommendation here is you do not make this file read-only .....
4. the application should then ignore the difference and not set/change any local timestamp due to 'local first' and 'upload only' but should be advising of a difference

There is an option to force the client to force Microsoft OneDrive to use the local file timestamp as well.

This option is 'force_session_upload' - https://github.com/abraunegg/onedrive/blob/master/docs/application-config-options.md#force_session_upload

This changes the upload method for every file, and forces the OneDrive API to use the timestamp of the local file.

As per the Microsoft API documentation, this method is used automatically for files larger than 4MB.