This means rclone does not handle the server response correctly and should answer with an error (so users get upset and start trolling Owncloud / Nextcloud developers to integrate this feature ^^)
EDIT: I started an issue at sabre/dav, but sadly the developer refuses to enable the getlastmodified property by default so everyone can update the file modification time. Please comment in this issue to support my idea so the developer hopefully rethinks his decision. Thank you!
No it's not. The clients (must) use the etag (by spec) and even if not, this means only that the client redown- or reuploads the file. And as this is a wanted behaviour from the user as he changed the timestamp, I don't really see the problem. The physical file on the server remains unchanged as this is only a virtual file property located in the database. It produces much more stress to delete and reupload everything.
At the moment I feel a little bit like fighting against an BDFL. I hope this dev rethinks his decision if other people support my point of view.
Yes.
Yes. This would be good. Or even better: Add the PROPPATCH method as described in my last command:
and if the server responses with 403 you use this for your debug / error process. Even if Sabre/Dav does not allow to overwrite this value maybe other WebDAV servers do.
I hope this method will be realized so we could bypass this limitation with the MOVE method:
Protected: SHOULD be protected because some clients may rely on the
value for appropriate caching behavior, or on the value of the
Last-Modified header to which this property is linked.
Which means that clients (ie rclone) shouldn't be allowed to modify it.
I agree with you that modification times would be really useful for rclone. However it is difficult to fight against the WebDAV RFC which doesn't think it is a good idea.
Yes and this is my argument. Its only "SHOULD" and not "MUST". This means by spec:
This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course."
By the way a funny part of this spec: It does not explain how to upload or create files through PUT. It even not describes if it is allowed to use the Overwrite header. This is only described for COPY and MOVE operations. ^^
And there is even a contradiction in the spec. While creationdate should be handled as follows:
This property value SHOULD be kept during a
MOVE operation, but is normally re-initialized when a resource is
created with a COPY.
The getlastmodified is described as follows:
The last-modified date on a resource SHOULD only
reflect changes in the body (the GET responses) of the resource.
A change in a property only SHOULD NOT cause the last-modified
date to change
This means if the WebDAV servers would interpret this strict, they would not be allowed to change the getlastmodified date on COPY operations, which would cause that the last modified date is older than the creation date ^^
And as creationdate is not protected it is possible to upload a file and set the creationdate through PROPPATCH to a newer date than getlastmodified. Does not make sense either.
P.S I contacted the IETF and requested them to add an update to the spec so it becomes more clear and reflects the users needs. I mean it can't be the target of the spec that some WebDAV softwares add special (and interoperable) variables (X-OC-MTime, srt_modifiedtime, etc) to bypass a limitation that nobody wants. Let's see if we achieve something through this way
You'll find if you do any work with WebDAV (like I have!) that the RFC isn't quite specified tightly enough and there are lot of quirks in WebDAV servers which need to be worked around. The webdav backend, for example, supports 4 different non RFC compliant time strings!