Hi, I am syncing from a crypt on Drive to a crypt on Dropbox where the only change is files is modtime (but modtime was changed on all files).
When trying to use --refresh-times to minimize unnecessary data transfer, I noticed the error in the debug log src and dst identical but can't set mod time without deleting and re-uploading so tried adding --server-side-across-configs to --refresh-times. (My hope was that the former flag could allow Dropbox to do a server-side copy, if necessary, just to update the modtime). Unfortunately, this didn't change anything and my otherwise unmodified files are all being flagged for transfer.
Is there currently a combo of features/flags that might enable rclone to simply change the modtime on my crypt-on-Dropbox remote without re-uploading (when it's a sync target from a crypt on Drive source)?
From what I can tell of the Dropbox V2 API, there is an indication that it is possible to update mtime via files_move_v2; however, presumably this requires a move to a temporary location, and move back to the original/desired location. Might this be worth supporting?
For good measure (and posterity), I asked via Dropbox Developer Support ticket and received the following (re-)confirmation:
H-----, Apr 4, 2023, 7:20 AM PDT:
Thanks for writing in. No, unfortunately the Dropbox API doesn't offer a way to update a file's 'client_modified' without uploading the file, but I'll pass this along as a feature request. I can't promise if or when that might be implemented though.
Not being familiar with the Dropbox API, I also asked whether a custom file_properties element might be an avenue for storing a timestamp as a mutable alternative to client_modified (as well as any anticipated trade-offs) and it was explained that file_properties are scoped to an app-user so do not seem a great alternative for rclone:
H-----, Apr 4, 2023, 8:19 AM PDT:
Yes, the Dropbox API offers "file properties" functionality which allows third party apps to set and get custom metadata. These file property values are only accessible to the specific app-user, so if you only need this information for your own app and only accessible to the connected user, you can use this as an alternative to relying on the standard 'client_modified'. Getting and setting file properties does not require re-uploading a file.
I would expect some minor performance cost as it would involve more server work to get/set file properties in addition to the standard file data and metadata operations when performing calls with the file properties included.
Also, file properties are completely under the control of the third party app and don't correlate to or sync with the standard file metadata fields such as 'client_modified', so custom file property and standard file metadata values would not be automatically consistent and you'd need to ensure your app uses one or the other in its logic as appropriate.
Apologies again for the noise! I'll certainly post any relevant updates I come across.