Hi,

I contribute to the Zoho WorkDrive backend of rclone, the open-source sync/copy tool. I would like to raise one specific, narrow API gap that currently makes reliable syncing to WorkDrive impossible, and ask whether it can be addressed.

What already works

When rclone uploads a brand-new file via POST /api/v1/upload, WorkDrive honours the x-last-modified-date header (ISO 8601, e.g. 2025-02-14T10:18:34.143Z) and the created file keeps its original modification time instead of the upload time. This header was confirmed to us through Zoho support, and I have verified it live on both the api/v1/upload and the stream/upload paths. It works exactly as intended, and I have shipped support for it.

What does not work

The same header is ignored when an existing file is updated. When the upload targets a name that already exists (override-name-exist=true, i.e. the version-revision path), the new version is always stamped with the current server time, and the header is silently dropped. The upload response shows "OPERATION":"UPDATE" with "updateType":"UPDATE_TYPE_REV_UPLOAD_FOR_SAMENAME", and both versionInfo.versionTime and resourceInfo.status_change_time are the upload instant. On the create path the same response instead shows "OPERATION":"UPLOAD" with AUDIT_INFO.resource.status_change_time equal to the timestamp I sent.

I have tested this exhaustively, and it is not a formatting or transport problem:

• Both upload endpoints (api/v1/upload and stream/upload).
• All three transports: request header, query parameter, and multipart form field.
• Both value formats: ISO 8601 and epoch milliseconds.
• Both header cases (X-Last-Modified-Date and x-last-modified-date) and both orderings relative to x-override-name-exist.
• Forward and backward timestamps (so it is not a "no times in the past/future" rule).

In every combination, create honours the value and update ignores it.

PATCH /api/v1/files/{id} does not offer a way out either: modified_time is recognised but read-only (string values return F000 UNABLE_TO_PARSE_DATA_TYPE, numeric values return a 500, and when paired with a valid attribute such as name the rename succeeds while modified_time is silently ignored and the file's modification time is bumped to the current server time). modified_time_in_millisecond, mtime and last_modified_time are all rejected as extra keys.

Why this one gap matters so much

Sync tools decide what to transfer by comparing the source and destination modification times. Because an updated file on WorkDrive always ends up with mtime = upload time, it can never match the source file's time. The result is that every subsequent sync run re-uploads the same unchanged files, forever — the sync never converges. This is not a cosmetic issue: it wastes bandwidth, and on a rate-limited API it produces repeated throttling.

The practical consequences today are severe. rclone has to declare that WorkDrive does not support modification times at all, which disables modification-time-based syncing, disables rclone bisync against WorkDrive entirely, and forces users onto --size-only — meaning a file that is edited without changing its size is silently never synced. A previous community attempt to add this support (rclone PR #8550) was closed with the conclusion that "the API is just ignoring all attempts to set the mod time" — which, I now believe, was exactly this create-vs-update difference being hit without it being understood.

Why I believe the platform can already do this

The WorkDrive server itself clearly stores a custom modification time per version — it is only the Public API that has no way to supply one.

I can observe this with Zoho's own tooling. If I create a file through the TrueSync desktop client with an old modification time and then overwrite it with different content and a different old modification time, WorkDrive's web version history shows two versions whose timestamps are the two custom modification times I set — not the real upload times. History stays intact, and each version carries its own client-supplied time.

So overwriting a file while preserving a client-supplied modification time is something the platform already supports and already does. TrueSync does not appear to go through the public api/v1/upload endpoint to achieve it, which would explain why this capability is simply not reachable for API clients.

My request

Please make the Public API able to set the modification time when updating an existing file — ideally by having api/v1/upload honour x-last-modified-date on the override-name-exist path exactly as it already does on create.

That is the only change needed. Create already works; update is the missing half. With it, rclone (and any other third-party sync or migration tool) could sync correctly to WorkDrive with full version history preserved. Without it, correct syncing to WorkDrive is not possible through the Public API.

Happy to provide full request/response dumps for any of the cases above if that helps.

Related rclone issues, for context: #8329 (where Zoho support confirmed the create header) and #7239.

Thanks,
Erol Ozcan