[Bug]: Hub9 30.0.2 (client 3.14.3) Fundamental: mtime on Server and Clients is Different #49189
Comments
Bockeman
added
0. Needs triage
|
Is this related? #48681 |
@XueSheng-GIT Thanks for pointing this out. It was one of the issues that popped up in my research, but I'm glad you mentioned this one, because I could have missed it. #48681 appears to be related to a "a frontend rendering issue". On occassions, I have also seen similar behaviour in my web rendered view with days or more of mtime difference. So I am inclined to agree that #48681 is an intermittent frontend rendering issue -- the webview has not caught up with the actual mtime stored on the server. This issue, on the otherhand is fundamental. The mtime stored on the server is wrong. |
|
I'm not a developer and I have not looked at the source code to work out what actually happens. Hypothesis
Presumed Issue Potential Solution |
|
I did another test. I copied some "old" files into the Experiment folder (I actually chose some of the "Nextcloud.*" files created upon installation about two weeks ago). I expected these files to not suffer the wrong mtime problem, but they do. I've checked all the possible timestamps on the server linux files. They all show the transfer time, not the installation/creating/last_modified time on the client. Here's the really weird bit. If I look on the web view (looking at the server files) I get: This web view is showing the correct "modified" date, 2 weeks ago. But this does not correspond to the mtime of those files on the server. |
Bug description
On a client machine where I am running nextcloud-client I create a file in a folder that is synchronised
with the server. Shortly after, that file appears on the server; the contents are identical, but the mtime is different.
This is a fundamental issue: files uploaded to the server should have their mtime preserved regardless of any delay in getting that file to the server storage.
I have been struggling with this issue for a long time because in my production environment it only manifests intermittently as a file conflict. But I have now created an environment where the mtime difference is present consistently for every file that is created or modified.
On my production server with over 20TB in use, the storage medium is not local HDD or SSD, but a network attached distributed storage with redundancy mounted as local storage (this is not external storage in nextcloud parlance). I am using glusterfs which serves me very well, robustly providing reliable storage despite HDD and machine failures over the years, but the specific file system itself is
irrelevant to this mtime difference issue. The feature of this file system that exposes the fundamental flaw in nextcloud is that accesses are slower than local SSD or HDD. I suppose that very occassionally, even local storage could have a longer than normal access delay, but the probability of that causing an mtime difference that in turn creates a file conflict is extremely low.
My fear is that many production nextcloud instalations are vulnerable to this issue, but the low probability means they are not suffering, or worse it requires too much effort to narrow down and report.
Steps to reproduce
Expected behavior
This is a fundamental issue: files uploaded to the server should have their mtime preserved
regardless of any delay in getting that file to the server storage.
Nextcloud Server version
30
Operating system
Other
PHP engine version
PHP 8.3
Web server
Apache (supported)
Database engine version
MariaDB
Is this bug present after an update or on a fresh install?
Fresh Nextcloud Server install
Are you using the Nextcloud Server Encryption module?
Encryption is Disabled
What user-backends are you using?
Configuration report
List of activated Apps
+ sudo -u apache php -f /usr/share/nextcloud/console.php app:list Enabled: - activity: 3.0.0 - app_api: 4.0.0 - bruteforcesettings: 3.0.0 - circles: 30.0.0 - cloud_federation_api: 1.13.0 - comments: 1.20.1 - contactsinteraction: 1.11.0 - dashboard: 7.10.0 - dav: 1.31.1 - federatedfilesharing: 1.20.0 - federation: 1.20.0 - files: 2.2.0 - files_downloadlimit: 3.0.0 - files_pdfviewer: 3.0.0 - files_reminders: 1.3.0 - files_sharing: 1.22.0 - files_trashbin: 1.20.1 - files_versions: 1.23.0 - firstrunwizard: 3.0.0 - logreader: 3.0.0 - lookup_server_connector: 1.18.0 - nextcloud_announcements: 2.0.0 - notifications: 3.0.0 - oauth2: 1.18.1 - password_policy: 2.0.0 - photos: 3.0.2 - privacy: 2.0.0 - provisioning_api: 1.20.0 - recommendations: 3.0.0 - related_resources: 1.5.0 - serverinfo: 2.0.0 - settings: 1.13.0 - sharebymail: 1.20.0 - support: 2.0.0 - survey_client: 2.0.0 - systemtags: 1.20.0 - text: 4.1.0 - theming: 2.5.0 - twofactor_backupcodes: 1.19.0 - updatenotification: 1.20.0 - user_status: 1.10.0 - viewer: 3.0.0 - weather_status: 1.10.0 - webhook_listeners: 1.1.0-dev - workflowengine: 2.12.0 Disabled: - admin_audit: 1.20.0 - encryption: 2.18.0 - files_external: 1.22.0 - suspicious_login: 8.0.0 - twofactor_nextcloud_notification: 4.0.0 - twofactor_totp: 12.0.0-dev - user_ldap: 1.21.0Nextcloud Signing status
Nextcloud Logs
Additional info
Operating system: Fedora 40
This issue is present on latest official Fedora versions:
Server 29.0.8
Client 3.13.4git
Also present on very latest version:
Server 30.0.2
Client Nextcloud-3.14.3-x86_64.AppImage
This is a standalone nextcloud environment freshly and specifically created for demonstrating this issue.
There are many related server and desktop issues reporting something amiss with mtime, but all have
been closed as stale or are restricted to something specific.
The text was updated successfully, but these errors were encountered: