Repository navigation
Consistent handling of last modified dates when copying/moving files #15192
Description
Is your feature request related to a problem? Please describe.
Nextcloud handles last-modified metadata inconsistently when copying and moving files and folders:
| Activity | Source | Destination | last modified preserved? v15 | last modified preserved? v16 | last modified preserved? v17 | last modified preserved? v18 | last modified preserved? v19 |
|---|---|---|---|---|---|---|---|
| file upload > 10 MB via browser | Desktop | Primary Storage | ✔️ | ✔️ | ✔️ | ✔️ | |
| file upload < 10 MB via browser | Desktop | Primary Storage | ⛔ | ⛔ | ✔️ | ✔️ | |
| file upload via browser | Desktop | External Storage | ⛔ | ⛔ | ⛔ | ||
| sync files with Desktop client | Desktop | Primary Storage | ✔️ | ✔️ | ✔️ | ✔️ | |
| upload files via WebDAV (@codiflow) | Desktop | Primary Storage | ⛔ | ⛔ | ⛔ | ⛔ | |
| download files via WebDAV | Primary Storage | Desktop | ✔️ | ⛔ | |||
| upload files via rclone | Desktop | Primary Storage | ✔️ | ✔️ | ✔️ | ||
| upload files via rclone | Desktop | External Storage | ⛔ | ⛔ | |||
| moving files and folders within nextcloud | Primary Storage | Primary Storage | ✔️ | ✔️ | ✔️ | ✔️ | |
| moving files and folders within nextcloud | Primary Storage | External Storage | ⛔ | ⛔ | ⛔ | ||
| moving files and folders within nextcloud | External Storage | Primary Storage | ⛔ | ⛔ | ⛔ | ||
| copy files and folders within nextcloud | Any Storage | Any Storage | ⛔ | ⛔ | ⛔ | ⛔ | |
| copying files via cloud federation | remote nextcloud | local nextcloud | ⛔ | ⛔ | |||
| upload via file drop | Desktop | primary storage | ⛔ | ⛔ | ⛔ |
(Primary storage refers to object storage directly managed by nextcloud, External Storage refers to externally mounted object storage.)
Describe the solution you'd like
Last-modification metadata should always be preserved, no matter where files and folders are coming from or moving to.
Describe alternatives you've considered
This should just work 😉
Additional context
For my use case, the last modification date of files and folders is critical for comparing different versions of the same item at different locations. It also is important when moving files from active usage into an archival storage (nearline bucket mounted externally).
Activity
codiflow commentedon Apr 23, 2019
I can add that uploading files into nextcloud by using WebDAV also doesn't preserve the original timestamps.
despens commentedon Apr 23, 2019
Thx @codiflow, added info to the table, please check if this is correct. Did you try with several WebDAV clients?
codiflow commentedon Apr 23, 2019
I use Krusader on Manjaro Linux and Windows Explorer on Windows 8.1 Pro. With both the timestamp will be set to now on upload. It also doesn't matter if the file is smaller or larger than 10 MB.
CherAlban commentedon Apr 24, 2019
I can confirm the <>10MB behavior with Firefox 66.0.3 (64-bit).
Using WebDav in BeyondCompare the timestamp always gets set to now on upload. (which is very annoying for my use case)
despens commentedon Apr 25, 2019
Using WebDAV via Gnome Shell, can confirm that last-modified dates are not preserved when moving items to nextcloud.
despens commentedon Apr 26, 2019
Updated table again, found out that copying data from nextcloud to local computer via WebDAV preserves last modified date.
codiflow commentedon May 29, 2019
I got a workaround for those who don't want to wait until this gets fixed:
It's somehow complicated but prevents me from the need to sync the entire nextcloud with my PC.
despens commentedon May 29, 2019
Tested with rclone and added to table.
despens commentedon May 29, 2019
Tested with nextcloud 16.0.1 and added to table.
despens commentedon Jan 1, 2020
Updated the table with some 17.0.2 tests. Great that files uploaded via browser now consistently keep their last modified info. Why is it different when using file drop though?
wrightsinreston commentedon Mar 1, 2020
Thanks for documenting this issue. I do not use a browser or WebDAV. Rather, I connect Win-10, Win-7, and Ubuntu clients to a NC v17 server running on a Raspberry Pi using the NC client apps. All the clients use the v2.6.3 NC client app appropriate for their OS architecture. When I change a synchronized file on any client, the NC server correctly synchronizes the updated content across all hosts as expected and the NC Web Admin page and Windows hosts all report the correct last-modified time. But the Ubuntu host reports the time at which the server synchronized it, which will differ for each Ubuntu client. This really confuses some java apps I've written which rely on last-modified time to make decisions. As you have noted in your write-up: "This should just work." And, at least, it should work the same way on all platforms. I do not consider this to be an Enhancement request and believe it should be registered as a bug.
wrightsinreston commentedon Apr 15, 2020
Here is some further information for those encountering this issue. I believe this offers a viable work-around even if the underlying issue appears to remain.
The issue appears to manifest itself only when the following three conditions are met: (1) The Nextcloud client is running on a Linux box, (2) the files in question are NOT owned by the UID of the running Nextcloud client process. (Note: Even if file permissions allow read/write, the file MUST be owned by the UID of the Nextcloud client process,) and (3) the disk volume on which the files in question reside is mounted under a UID different from that of the file owner. If all three of those criteria are met, Nextcloud will be unable to set the Last-Modified time and the time-stamp will reflect the time at which the file was synchronized.
If the disk volume is mounted under the same UID as the running Nextcloud client process (even if it resides on a different host PC) or if it is mounted as a CIFS volume, then the issue vanishes and Nextcloud can successfully set the time-stamp as expected.
This appears to be unique to Linux hosts. Windows hosts do not appear to manifest this issue regardless of file ownership or file system.
Kuphi commentedon Jun 5, 2020
@despens can you update your table for nextcloud 18 and 19? Thank you! 🥇
41 remaining items
da-anda commentedon Mar 2, 2024
It is a nexcloud bug. Users don't care which protocol is used in the background when they sync data using their official apps. And nobody forces nextcloud to internally use WebDAV. Also, nextcloud could extend the official WebDAV API with additional features that are not (yet) part of the standard to fix this (and other issues), like sending an additional custom header.
If you use other WebDAV clients to sync data to NC, then it's ofc a different story. But at least official apps should keep crdate etc
evrial commentedon Mar 2, 2024
Agree that WebDAV API and RFC need an update. What doesn't work is native OS clients and web browsers because it's not a part of standard.
https://docs.nextcloud.com/server/latest/developer_manual/client_apis/WebDAV/basic.html#request-headers
despens commentedon Mar 4, 2024
It is true that nextcloud cannot mandate external clients to support nextcloud's extension to the WebDAV protocol that transfers modtime dates. For instance, rclone supports modtime on upload with WebDAV.
However, when data is transferred in between different nextcloud instances, or using tools that are part of the nextcloud project, I would expect this critical information not be lost.
That is the case when using
micha06de commentedon Mar 7, 2024
We have Nextcloud 27.1.7.2 here, and I was surprised to discover today that the last modified timestamp is not retained when copying within the Nextcloud web app (it is retained when moving). I seem to remember that this used to be different.
Does anyone know to confirm that this is "normal" behavior, or is there something wrong with our server configuration?
skjnldsv commentedon Aug 9, 2024
Upgrade to 28 or 29. We fixed it as far as I know.
emanueleriboldi commentedon Sep 15, 2024
Still doesn't work. I'm using NC 29 and when copying files from PC to Network Drive Share (via WebDAV), the last modified date is the time when I copy the file.
lucidnx commentedon Sep 15, 2024
it is crazy that it's still not fixed after long time... this is one of important functions!
KlausBlum commentedon Sep 15, 2024
I'm not sure the error is on the nextcloud side.
The table above mentions rclone as upload tool that retains the correct file date and time. IIUC rclone uses the WebDAV protocol plus some extra tricks to manipulate the file date which obviously is accepted by nextcloud.
I have been using a combination of rclone and FreeFileSync for the last few months now, and it works without problems (despite being significantly slower than "pure" WebDAV).
despens commentedon Sep 24, 2024
@KlausBlum There is no single error here, but depending on tools and protocols used, nextcloud sometimes retains last modified information and sometimes not, including internal movement of data in between different storage backends, or in between nextcloud instances, where no external tool is used.
aboulan commentedon Mar 10, 2025
Hello,
It seems that modification date is not preserved either when copying files from personal folder to a group folder (within the web interface)
Rudd-O commentedon Jun 16, 2025
This just bit me. Moving files between external storages (two different folders in the same SAMBA server, configured as separate file shares on a Nextcloud profile) completely rekt the modifications dates of the files. I am quite unhappy. I'll have to go back to ZFS snapshots for these...
drago1520 commentedon Dec 5, 2025
Still not fixed. Uploading from IOS, even with the original photo, doesn't work in the web interface.
Thebinoman commentedon Apr 17, 2026
Not being able to preserve the timestamps of my folders from my current drive is the only deal breaker, keeping me from migration from my current drive that I've been using for years.
Being able to modify the folder timestamp, or at the very least preserve the timestamps of uploaded folders from desktop sync will make all the difference.