Modification times of Nextcloud/Owncloud files were not updated

I tried to update file modification times through the following command:

rclone sync -P --ignore-checksum -vv /mnt/user/Music/ /mnt/disks/owncube/Musik/

As you can see Unraid says it worked (full logs):

2020-06-22 01:34:13 DEBUG : Modification times differ by 25h51m58s: 2020-01-05 23:28:0
7 +0100 CET, 2020-01-07 01:20:05 +0100 CET
2020-06-22 01:34:48 DEBUG : MD5 = 8df15abbe51f4b120532f5540624f469 OK
2020-06-22 01:34:51 INFO  : Updated modification time in destination
2020-06-22 01:34:51 DEBUG : Unchanged skipping

But the files on the server were not updated!

Which command is build through rclone to update the file through webDAV: MOVE, PROPPATCH... ? And how is the server response handled?

I tried many many different cURL commands and I'm not able to update the file modification time, too.

It seems Nextcloud does only accept the X-OC-Mtime header for file uploads (PUT).

EDIT: Yes, only Connector/Sabre/File.php -> put() contains the X-OC-MTime check. Connector/Sabre/Directory.php -> moveInto() misses it. :sob:

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!

I read that thread.

It seems that the modtime of the file is important to the internal syncing mechanisms so I think they are unlikely to change this.

I presume you are syncing to /mnt/disks/owncube/Musik/ which is a webdav mount?

Hmm, rclone is hiding the truth from you here

The webdav backend will return fs.ErrorCantSetModTime which means that in order to set the mod time you need to upload the file again.

Perhaps at least rclone should DEBUG the fact that it didn't really set the mod time - what do you think?

If you synced direct to the webdav rather than the mount then rclone would re-upload the file to fix the timestamp.

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. 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:

I tried setting the getlastmodified property with PROPATCH when I was writing the backend.

However the RFC says this

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 :wink:

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!

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.