Hi @budowski,
Thanks for reaching out about this!
The error indicates that there is a remote file that has changed, but its remote timestamp is older than the timestamp for the same file on your local computer.
Here is an example of a file that is reporting this (I replaced your names in the path with … ):
30 Oct 03:24:18PM INFO Attempting to update a local file from remote. File: /Users/…/odrive/Dropbox/…/Photos/Trips/United Arab Emirates/2023/929002783_76.jpg - Current Remote Size: 2265061 - Previous Remote Size: 2264721 - Local Size: 2264721 - Current Remote Date: 2023-02-10 01:57:00 - Previous Remote Date: 2023-02-10 01:57:00 - Local Date: 2023-02-10 01:57:58
30 Oct 03:24:19PM ERROR Failed Download (Update) for Item: /Users/…/odrive/Dropbox/…/Photos/Trips/United Arab Emirates/2023/929002783_76.jpg - Size: 2265061 Bytes - Date: 2023-02-10 01:57:00 - Error: code FS112 caused by RemoteOlderThanLocalException(code FS112 - The remote file modtime 1675965420 is older than the local file modtime 1675965478)
The remote file changed size from 2264721 to 2265061 (increased by 340 bytes)
The remote date was unchanged: 2023-02-10 01:57:00
The local size is currently: 2264721 (340 bytes smaller than remote)
The local date is currently: 2023-02-10 01:57:58
So the local file has a timestamp that is 58 seconds newer than the observed remote file timestamp.
The reason this error is currently showing is because there is a default safety feature in odrive that prevents older remote files from overwriting newer local files. Almost always a file update is going to have a newer date, so when it has an older data it is considered to be abnormal. This is to prevent a scenario, for example, where someone accidentally uploads an older version of a file and that version syncs and overwrites all local copies too.
This check can be disabled with an advanced feature
Your scenario looked odd, so I did some debugging and discovered that we have a bug that doesn’t handle the remote modification time seconds properly (always zeroed). I have submitted a fix for review for this to be addressed in the next release. I guess this went unnoticed because normally file updates will change the remote modtime and that is typically going to differ by more than a minute. Additionally, Dropbox remote change detection is based on the file’s content tag instead of by date changes, so the small variation of the modtime seconds doesn’t normally have any effect. It actually only comes into play in your particular case where the remote content has changed but the remote date has stayed the same.
You mentioned that the changes you made were on your local machine and uploading to the remote, which doesn’t fit this particular error because this is a case where a odrive is observing that the remote file content was changed (content tag changed).
Q: Is this on a different computer than where the files were recently modified?