-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Modified date - Uploaded date #21762
Comments
@MTRichards @dragotin what do you think? |
Short story: This is by design. Longer story: It has been this way because, unless we touch the file and update the mtime on the server when uploaded through the web, that is considered the time the file was created. For whatever reason, browsers behave that way. not sure who might know if this is addressable, I am unaware of a way to address this. On the desktop sync, we touch the file at the end of the upload so that the mtime on the server matches the mtime on the desktop. This is by design, and should be this way - so when you collaborate, this was the last "version" and everyone is lined up with what the various operating systems say. This is why sync is good. The argument here to make is that they are different, and to force the web upload process to touch the file and change the mtime to what the file is on the local machine when uploading....but here is the thing, I don't know if this is possible with web browsers. |
well in 'modern' browsers you can these days get the file mtime on upload. But lets look at it in a different way. Uploading a file trough the webinterface is an action taken by the user. While uploading a file trough the desktop client is a passive action. I.e. I edit the file and I let the sync client sync it when it can. If for some reason the file can't be synced at the moment I edit it (maybe I'm traveling and there is no wifi). Then when I get home all files are uploaded. Which is weird because then all of a sudden all the files I have touched are dated at 21:00 or something. I would argue that the web interface need to be changed to add the mtime of the uploaded file. |
@jancborchardt For your thoughts. |
@rullzer says it: While the upload through web interface is an user action done "on purpose", the sync happens in the background and is not really visible to the user. My vote would be to leave that as it is. |
Leaving it like this creates confusion. I am actually surprised nobody reported it until now. From: Klaas Freitag [mailto:notifications@github.com] @rullzerhttps://github.com/rullzer says it: While the upload through web interface is an user action done "on purpose", the sync happens in the background and is not really visible to the user. My vote would be to leave that as it is. — |
Note: with my work on Webdav PUT #21237 it will become possible to keep the mtime of the file that was uploaded with a decent browser that provide this info/API. Might not work in IE though. |
From a UX point of view, the modified date/time of the file on the server should of course always be exactly the same as the modified date/time on any of the clients. Anything else is confusing as pointed out. It was maybe solved otherwise so far because of aforementioned technology limitations, but never by design. |
In your example, I think the error is that the notification mail shows the 16:00 timestamp. It should be 9:00 oclock IMO. |
@dragotin I think that would be confusing as well. Since then people might think why do I get the e-mail just now! Basically we would need additional meta data. We have the mtime wich is just the modification time of the file. And then as meta data we have the upload time of the file. Both mean something different but both can be useful info for users. |
@rullzer It’s fine if a notification mail arrives slightly later than the actual modification (as long as it’s not too long). The important thing is that there should be no mail notification if the change was already viewed via the web interface (but that’s a slightly different issue). |
Setting to 9.1 to match #21237 which provides this for decent browsers. |
Starting with 9.2, uploading with a recent web browser will use the mtime of the actual file instead of upload date. Unless the browser doesn't expose that. |
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. |
Hello,
If I upload a file via the web interface, the "Modified" column on the server appears as it should be. Example: I upload the file at 14:00 and I look at it via the web interface after one hour, it says "Modified" "an hour ago", as it should be.
If I sync a file via the owncloud client and later I look at it via the web interface, the "Modified" column displays the time/date when the file was modifed in windows, not the time when it was uploaded on the server (via the client).
Example: I put a doc file (the windows file modified attribute shows 09:00, as that is the last time the file was modified on the windows machine) in the owncloud client at 14:00.
I have a look at this file via the web interface after on hour, and, instead of displaying "Modified one hour ago" it displays "Modified" 4 (four) hours ago...taking into account the time/date when the file was modified on windows, not the time/date when the file was uploaded.
This screws up the notification mails, of course.
Thank you
server version 8.0.10, windows client version: 2.1
The text was updated successfully, but these errors were encountered: