After upgrading to 1.66.0 from 1.65.2, running rclone to sync a local directory to OneDrive is prompting to reupload many files that haven't changed due to an apparent difference in time tolerance from 1s to 1ms. The release notes didn't indicate this as a change in 1.66.0 so I am wondering if this is expected behavior or not.
Run the command 'rclone version' and share the full output of the command.
rclone v1.66.0
os/version: arch (64 bit)
os/kernel: 6.8.2-arch2-1 (x86_64)
os/type: linux
os/arch: amd64
go/version: go1.22.1
go/linking: dynamic
go/tags: none
Which cloud storage system are you using? (eg Google Drive)
OneDrive
The command you were trying to run (eg rclone copy /tmp remote:tmp)
Please run 'rclone config redacted' and share the full output. If you get command not found, please make sure to update rclone.
[onedrive-YYY]
type = onedrive
link_scope = organization
token = XXX
drive_id = XXX
drive_type = personal
[onedrive-YYY-ZZZ]
type = crypt
remote = onedrive-YYY:/redacted
password = XXX
### Double check the config for sensitive info before posting publicly
A log from the command that you were trying to run with the -vv flag
Relevant part of the log file:
2024/03/31 16:34:25 DEBUG : redacted/file-1: Size and modification time the same (differ by 0s, within tolerance 1ms)
2024/03/31 16:34:25 DEBUG : redacted/file-2: Modification times differ by -773.323763ms: 2023-05-08 13:21:37.773323763 -0400 EDT, 2023-05-08 17:21:37 +0000 UTC
Note that some files are showing a difference in modification time of <1 second which would have been considered equivalent under the previous tolerance of 1s but are now prompting to be updated under the new tolerance of 1ms.
I have validated that the modification time of these files have not been changed locally by comparing against a local rsync backup taken a few weeks ago that their timestamps match precisely.
Did something in regards to modification time resolution change recently in rclone? The release notes here did not indicate this would be changing: Documentation
Nothing was updated on the remote, however. The debug logs show that it is still checking for a 1s difference despite the presence of the --modify-window 1ms argument:
2024/03/31 23:18:15 DEBUG : redacted/file-1: Size and modification time the same (differ by -313.76891ms, within tolerance 1s)
I thought --modify-window 1ms was supposed to override this tolerance. Does it not work this way?
Interestingly, if I run with --modify-window 2s, the 2s value is apparently honored as I would expect and can be seen in the debug log below. Is a --modify-window below 1s not supported?
2024/03/31 23:22:21 DEBUG : redacted/file-2: Size and modification time the same (differ by -344.443927ms, within tolerance 2s)
--modify-window can make the window larger than the remote's default, but not smaller.
Since you're on v1.65.2, the default is 1s, and so --modify-window cannot make it smaller than 1s. (With v1.66.0, it could.)
If I'm understanding your goal correctly, I think you might want to go the reverse direction. i.e. upgrade to v1.66.0 and sync remote to local without --modify-window, thereby truncating the local timestamps to match what you have on the remote.
Makes sense, I upgraded back to 1.66.0 and re-ran the command with --refresh-timestamps --modify-window 1ms and it did what I expected to: update the timestamps on the remote to match my local files with 1ms tolerance.
My local files are my primary copy and the remote is purely a backup, which is why I wanted to sync in the direction of local->remote.
Thanks for your clarifications. BTW rclone is wonderful software!