dont preserve mtime when uploading trough the web interface

[icewind1991]

While mtime preservation is expected behaviour when using the sync client I think preserving mtime while uploading trough the web interface is not expected.

[mention-bot]

@icewind1991, thanks for your PR! By analyzing the history of the files in this pull request, we identified @schiessle, @butonic and @luckydonald to be potential reviewers.

[codecov-io]

Codecov Report

Merging #3822 into master will not change coverage.
The diff coverage is n/a.

@@ Coverage Diff @@## master #3822 +/- ##
=========================================
Coverage 54.29% 54.29% Complexity 21053 21053 =========================================
Files 1302 1302 Lines 80280 80280 Branches 1254 1254 =========================================
Hits 43586 43586 Misses 36694 36694

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4395cf4...ad4b5c8. Read the comment docs.

[LukasReschke]

I think I do second this. Just had a customer last week complaining about this behaviour as well :)

[luckydonald]

Please don't bump me.

[nickvergessen]

@luckydonald sorry, you already saw that mention bot ignores the ignore list.
If you don't want to be bothered anymore, please make use of this github feature:

[wowangus]

I suspect that not preserving mtime might very likely will affect the integrity of the data being uploaded and affect the truth of last modification timestamp of the file.

there should not be any differences between uploading through web interface, or desktop sync, or mobile apps. mtime should always be kept for sack of telling the truth about when is it eventually modified even you revisit and review a file 1/3/5/10/15 years later.

[wowangus]

@icewind1991@nickvergessen Please reconsider the effect of not preserving mtime of a file being upload through the web ui. Preserving mtime is always expected when transferring a file from/to internal drive/flash drive/network drive/memory card/mobile phone.

Consider the following scenario:

1. USER_A have a batch of document/image/video, taking photos as example in this case, that are taken/edited/modified 4~6 months ago.
2. USER_A recently uploads those photos through web ui to Nextcloud.
3. USER_A tries to sort uploaded photos by their last modified date in web ui or mobile app or sync client's folder, and expects that would behave similarly as how file explorer does with the original folder.
4. USER_A however cannot get the expected sorting, instead those files are now sorted by their uncertain sequence of upload, because the mtime is not retained/preserved at/as of web-ui uploading, and mtime of those files are lost then replaced with their upload time (e.g. if connection is slow, upload time would take quite a while, probably like 09:00 for photo002, 09:01 for photo001, 09:02 for photo003).

Please reconsider the effect of not preserving mtime and consider reverting the merged changes.

I have also #3572 and nextcloud/files_retention#23 about the issue regarding file retention module. The issue there should be fixed by making use of "upload datetime timestamp" for the retention decision logic instead. That issue should not be fixed by abandoning mtime as of web-ui uploading.

Thanks for your attention!

[nickvergessen]

I totally agree

[f11h]

Is there any chance that this "feature" will be reverted to old behaviour?
Since we use NC12 my users are a little bit confused about the "faked changed times" (some of them are only using WEB-UI)

Currently I've reverted the corresponding js-file to the old version, but this isn't the way I should do it 😃

[wowangus]

Totally understood the confusion caused by the false "last-modified" timestamp.

The real last-modified timestamp of any particular uploaded files should always be retained throughout the journey and workflow between front-end and back-end.

Hope communities could see the issues and consequences of the behaviour and revert it.

[zestoi]

i just added back in the code that had been removed from apps/files/js/file-upload.js as i need the file modified timestamp not when it was uploaded. guess this isnt the best thing to do but works fine for me now.

[icewind1991]

While I still maintain the opinion that the current behaviour makes the most sense as a default, I understand that the old behaviour has valid use cases.

To "solve" the problem I created a small app that reverts the behaviour to the pre-12 behaviour: https://github.com/icewind1991/files_upload_mtime

The app isn't the cleanest way to handle it (dynamically modifying core js...) but it at least removes the need to manually modify the js.

[f11h]

Hi icewind1991, thanks a lot, this really helps me. I think this is the most elegant way we could do it :)

[Frogging101]

I think this behaviour should at least be made optional. I expect a file storage system to preserve metadata when I upload files to it.