Skip to content
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

Closed
mihaig11 opened this issue Jan 16, 2016 · 14 comments
Closed

Modified date - Uploaded date #21762

mihaig11 opened this issue Jan 16, 2016 · 14 comments

Comments

@mihaig11
Copy link

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

@karlitschek
Copy link
Contributor

@MTRichards @dragotin what do you think?

@MTRichards
Copy link
Contributor

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.
Not sure who might know the answer to that, but as far as I know web browsers treat all uploads as new files at the time of upload, and the mod time can't be changed because you don't know what the file mod time is in the browser.

@rullzer
Copy link
Contributor

rullzer commented Jan 16, 2016

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.
What would be a nice enhancement is also saving the upload time. Which we can store as meta data.

@MTRichards
Copy link
Contributor

@jancborchardt For your thoughts.
This is a significant change, and with so many installations out there, not one to be considered lightly.

@dragotin
Copy link
Contributor

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

@mihaig11
Copy link
Author

Leaving it like this creates confusion. I am actually surprised nobody reported it until now.
What actually happened in our case: I modified some files at 09:00 and sync them (via owncloud client) at 16:00…files were uploaded in a folder already shared with a client, so she received a mail notification saying new files were created at 16:00…but when she logged in owncloud (via the web interface) she saw the files “modified” column showing 09:00. For most people, “Modified” column means when the files were uploaded.
Even worse would be to upload several files, some of them via web and other via the client. Let’s say I do this at 12:00. In this case, the client will receive a mail notification saying all files were created at 12:00…while on the web interface she will see some of the files (ones uploaded via the web) “modified” at 12:00 and the others (ones uploaded via client) a day ago (or whatever their “local” mdate is).
Makes more sense to have the same “modified” time/date on the web interface, no matter how you upload your files…or maybe having an extra “Uploaded” column, as already suggested.

From: Klaas Freitag [mailto:notifications@github.com]
Sent: samedi 16 janvier 2016 21:34
To: owncloud/core
Cc: Mihai Genescu
Subject: Re: [core] Modified date - Uploaded date (#21762)

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


Reply to this email directly or view it on GitHubhttps://github.com//issues/21762#issuecomment-172255997.

@PVince81
Copy link
Contributor

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.

@jancborchardt
Copy link
Member

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.

@dragotin
Copy link
Contributor

In your example, I think the error is that the notification mail shows the 16:00 timestamp. It should be 9:00 oclock IMO.

@rullzer
Copy link
Contributor

rullzer commented Jan 18, 2016

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

@jancborchardt
Copy link
Member

@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).

@PVince81
Copy link
Contributor

Setting to 9.1 to match #21237 which provides this for decent browsers.

@PVince81 PVince81 added this to the 9.1-next milestone Feb 11, 2016
@PVince81 PVince81 modified the milestones: 9.1-current, 9.2-next Jun 14, 2016
@PVince81
Copy link
Contributor

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.

@lock
Copy link

lock bot commented Aug 3, 2019

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.

@lock lock bot locked as resolved and limited conversation to collaborators Aug 3, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

8 participants