How to preserve timestamps

[drzraf]

Following:

• owncloud's webdav: preserve timestamps lavv17/lftp#237
• Respect mod_unique_id and refactor OC_Request::getRequestId #13973 (comment)

There are two questions/clarifications here:

• how a client is expected to preserve timestamp of a file PUT to ownClound through WebDAV?
• What's the purpose of X-OC-MTIME?

[PVince81]

@drzraf thanks for the ticket.

@guruz @ogoffart @davivel @jvillafanez does the desktop client or mobile client still use the X-OC-MTIME header ?

From what I remember its value meant "server has accepted the mtime". It was there for the server to tell the client whenever an external storage does not support the touch operation (ex: SMB). Whenever the client would receive that header, it would issue a PROPPATCH with "lastmodified" to explicitly set the mtime again.

Not sure why, it doesn't seem to make sense now. Maybe it made sense back then.

Currently the storage behavior already has a fallback: whenever the storage does not support the touch() operation, the server will save the mtime inside the "oc_filecache.mtime" column which is the mtime exposed to the web UI and the clients. However, the mtime as exposed by the storage (the one that could not be updated) is stored in "oc_filecache.storage_mtime" and is only used internally to detect remote changes done on the external storage (without going through ownCloud).

Is it time to retire this header ?

[davivel]

Android client doesn't use it.

cc @javiergonzper for iOS client.

[PVince81]

Okay, now I realize that there are two such headers.

As input header, when uploading with PUT, the client sets "X-OC-MTIME" to the mtime of the local file.
I suppose this might be because one cannot set "LastModified" header in a PUT operation. Or is that allowed ?

Now as a response header, there's "X-OC-MTIME: Accepted". This is what I meant above about the server accepting the mtime.

[PVince81]

Hmm, somehow it looks like if with GET or HEAD you send a "Last-Modified" header, it means you expect some kind of caching to kick in: https://tools.ietf.org/html/rfc7232#section-2.4

There is no note about PUT, but I could imagine that the semantics could be similar.

[drzraf]

While dating back from 2014 I found the following from @evert insightful:
https://groups.google.com/forum/#!topic/sabredav-discuss/rXZ6n7_WPtk
... but I fear nothing significantly changed since that time.

[davivel]

As input header, when uploading with PUT, the client sets "X-OC-MTIME" to the mtime of the local file.

True, and we should be doing so in mobile clients. There is a bug open about this, at least in Android repo.

I suppose this might be because one cannot set "LastModified" header in a PUT operation. Or is that allowed ?

Doesn't seem so.

The Last-Modified entity-header field indicates the date and time at which the origin server believes the variant was last modified.

From: https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.29

[davivel]

Hmm, somehow it looks like if with GET or HEAD you send a "Last-Modified" header, it means you expect some kind of caching to kick in: https://tools.ietf.org/html/rfc7232#section-2.4

Don't you think that the "send" there refers to the server including the "Last-Modified" header in the response? I think the involved header in the request side is "If-Modified-Since" . https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.25

[guruz]

Before we used the ETag to identify file changes, we worked a lot with the mtimes and set that using this X-OC-MTime header...
https://github.com/cernbox/smashbox/blob/master/protocol/protocol.md

[PVince81]

I thought we used X-OC-MTime mostly to be able to keep the same mtime of files on the client and the server. It wouldn't be useful for the server to show the mtime as the upload time from a user's perspective. So either way we need a way to tell the server what mtime to set to the file.

[ogoffart]

@PVince81: exactly.

The client used to do a PROPPATCH if the server did no reply with X-OC-MTime: accepted. But today the client no longer support such old server and does no longer do it (and throw an error if it is not there)

[PVince81]

So we could at least get rid of the response header "X-OC-MTime: accepted".

[guruz]

So we could at least get rid of the response header "X-OC-MTime: accepted".

No because the client would error then :-)

    if (job->reply()->rawHeader("X-OC-MTime") != "accepted") {
        // X-OC-MTime is supported since owncloud 5.0.   But not when chunking.
        // Normally Owncloud 6 always puts X-OC-MTime
        qWarning() << "Server does not support X-OC-MTime" << job->reply()->rawHeader("X-OC-MTime");
        // Well, the mtime was not set
        done(SyncFileItem::SoftError, "Server does not support X-OC-MTime");
    }

[lavv17]

I suppose this might be because one cannot set "LastModified" header in a PUT operation. Or is that allowed ?

Doesn't seem so.

It's not prohibited either. Last-Modified is an entity header (section 7.1) and an entity is being sent in a PUT request. So the client could add the Last-Modified header for the entity. But I agree that the RFC 2616 does not explicitly specify such usage of the header.

[PVince81]

The solution currently is pass the "X-OC-Mtime" header in the PUT operation of the upload. Since OC 10.0 the web UI also does so.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.