Is it possible to set client_modified on an existing file in v2 API?

[ncw]

Being able to set client_modified on an existing file would be really helpful for rclone.

I looked through the API methods and couldn't see a way but I'm hoping I missed it!

Thanks

Nick

[Alexandra F.1]

It's not currently possible to override the client_modified value set by the client using the API, but I'll be sure to pass this along as a feature request.

[bliang]

Is there any update on this feature request?

[Greg-DB]

The upload endpoints, such as /2/files/upload, do now allow you to explicitly set `client_modified` when uploading a new version of a file. 

For reference, do you need to be able to do so without uploading a new version?

[ncw]

> For reference, do you need to be able to do so without uploading a new version?

Yes that would be ideal.

Rclone uses `client_modified` to save the modification times of files.  If a user just does `touch file` then it would be nice to be able to just set the `client_modified` without upload the whole file again.

At the moment rclone will upload the whole file again just to set the modification time which is a bit wasteful.  Perhaps there is a better way?

Thanks

Nick

[Greg-DB]

@ncw Thanks for the context! There isn't a way to that on the Dropbox API unfortunately, but I'll send it along as a feature request.

[ncw]

Related to that...  If you actually want to upload a the same file with a different `client_modified`, you have to delete the existing file first.

If you don't delete the existing file first, then the upload succeeds, but somehow it has the old `client_modified`, not the new one you just specified in your upload.

I suspect this is upload process checking the hash and noting that the file content is the same after the upload and deciding not to do anything further with the data.

You can work around this by deleting the file first (which is what rclone does) but this isn't ideal as it makes data loss more likely if the transfer of the new file fails.

I'm not sure whether this is part of the same feature request, or whether it it a seperate bug report!

If you think it should be a bug report I'm happy to write it up in more detail with some HTTP API transactions to show exactly what is going on.

Thanks

Nick

[Greg-DB]

@ncw That behavior is expected. From the /2/files/upload WriteMode docs:

"If the target path refers to a file with identical contents, nothing gets written; no conflict."

[ncw]

I see - thank you for explaining. I don't like this design choice, but it is documented so I'll live with it 🙂

Looking forward to an API to set the client_modified time!

Thanks for your help @Greg-DB

[Greg-DB · Accepted solution]

Just to be clear, I've sent this feature request along, but I can't promise if/when it might be implemented.