Corrupted file timestamps #30263

Tie-fighter · 2021-12-14T10:33:26Z

Steps to reproduce

Try to make an directory available offline
Nextcloud Desktop client 3.4.0 crashes
Restart Desktop Client
Crashes again and again (Even got a bluescreen once)
Desktop Client starts uploading files

Expected behaviour

Directory gets downloaded

Actual behaviour

Files have a filesystem date of 1.1.1970, version restore says "invalid date", files get uploaded again.

Server configuration detail

Operating system: FreeBSD 12.2-RELEASE-p10 FreeBSD 12.2-RELEASE-p10 b26f74b5984(HEAD) TRUENAS amd64

Webserver: nginx/1.20.1 (fpm-fcgi)

Database: mysql 10.5.13

PHP version:

8.0.13
Modules loaded: Core, date, libxml, pcre, hash, json, Reflection, SPL, session, standard, cgi-fcgi, mysqlnd, apcu, bcmath, bz2, ctype, curl, dom, mbstring, fileinfo, filter, gd, gmp, iconv, imagick, intl, exif, openssl, PDO, posix, SimpleXML, xml, xmlwriter, zip, zlib, pdo_mysql, xmlreader, Zend OPcache

Nextcloud version: 23.0.0 - 23.0.0.10

Updated from an older Nextcloud/ownCloud or fresh install:

Where did you install Nextcloud from: unknown

Signing status

Array
(
)

List of activated apps

Enabled:
 - accessibility: 1.9.0
 - activity: 2.15.0
 - admin_audit: 1.13.0
 - announcementcenter: 6.1.1
 - bookmarks: 10.0.3
 - bruteforcesettings: 2.2.0
 - calendar: 3.0.1
 - checksum: 1.1.3
 - circles: 23.0.0
 - cloud_federation_api: 1.6.0
 - comments: 1.13.0
 - contacts: 4.0.6
 - contactsinteraction: 1.4.0
 - dashboard: 7.3.0
 - dav: 1.21.0
 - deck: 1.6.0
 - federatedfilesharing: 1.13.0
 - federation: 1.13.0
 - files: 1.18.0
 - files_pdfviewer: 2.4.0
 - files_rightclick: 1.2.0
 - files_sharing: 1.15.0
 - files_trashbin: 1.13.0
 - files_versions: 1.16.0
 - files_videoplayer: 1.12.0
 - firstrunwizard: 2.12.0
 - impersonate: 1.10.0
 - issuetemplate: 0.7.0
 - logreader: 2.8.0
 - lookup_server_connector: 1.11.0
 - maps: 0.1.9
 - metadata: 0.15.0
 - nextcloud_announcements: 1.12.0
 - notifications: 2.11.1
 - oauth2: 1.11.0
 - password_policy: 1.13.0
 - photos: 1.5.0
 - privacy: 1.7.0
 - provisioning_api: 1.13.0
 - recommendations: 1.2.0
 - serverinfo: 1.13.0
 - settings: 1.5.0
 - sharebymail: 1.13.0
 - spreed: 13.0.1
 - support: 1.6.0
 - survey_client: 1.11.0
 - suspicious_login: 4.1.0
 - systemtags: 1.13.0
 - tasks: 0.14.2
 - text: 3.4.0
 - theming: 1.14.0
 - twofactor_backupcodes: 1.12.0
 - twofactor_totp: 6.2.0
 - updatenotification: 1.13.0
 - user_status: 1.3.1
 - viewer: 1.7.0
 - weather_status: 1.3.0
 - workflowengine: 2.5.0
Disabled:
 - apporder
 - backup
 - duplicatefinder
 - encryption
 - files_external
 - files_texteditor
 - polls
 - previewgenerator
 - registration
 - socialsharing_email
 - twofactor_gateway
 - user_ldap

Configuration (config/config.php)

{
    "instanceid": "***REMOVED SENSITIVE VALUE***",
    "passwordsalt": "***REMOVED SENSITIVE VALUE***",
    "secret": "***REMOVED SENSITIVE VALUE***",
    "trusted_domains": [
        "next.thomas-steinbrenner.net"
    ],
    "datadirectory": "***REMOVED SENSITIVE VALUE***",
    "dbtype": "mysql",
    "version": "23.0.0.10",
    "dbname": "***REMOVED SENSITIVE VALUE***",
    "dbhost": "***REMOVED SENSITIVE VALUE***",
    "dbport": "",
    "dbtableprefix": "oc_",
    "dbuser": "***REMOVED SENSITIVE VALUE***",
    "dbpassword": "***REMOVED SENSITIVE VALUE***",
    "installed": true,
    "loglevel": 3,
    "mysql.utf8mb4": true,
    "maintenance": false,
    "mail_domain": "***REMOVED SENSITIVE VALUE***",
    "mail_from_address": "***REMOVED SENSITIVE VALUE***",
    "mail_sendmailmode": "smtp",
    "mail_smtpdebug": true,
    "mail_smtpmode": "smtp",
    "mail_smtpauthtype": "LOGIN",
    "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
    "mail_smtpauth": 1,
    "mail_smtpport": "465",
    "mail_smtpname": "***REMOVED SENSITIVE VALUE***",
    "mail_smtppassword": "***REMOVED SENSITIVE VALUE***",
    "mail_smtpsecure": "ssl",
    "updater.release.channel": "stable",
    "theme": "",
    "memcache.local": "\\OC\\Memcache\\APCu",
    "overwrite.cli.url": "https:\/\/next.thomas-steinbrenner.net",
    "logfile": "\/var\/log\/nextcloud\/nextcloud.log",
    "app_install_overwrite": [
        "bruteforcesettings",
        "issuetemplate"
    ]
}

Are you using external storage, if yes which one: local/smb/sftp/...

Are you using encryption:

Are you using an external user-backend, if yes which one: LDAP/ActiveDirectory/Webdav/...

Client configuration

Browser: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.93 Safari/537.36

Operating system:

Logs

Web server error log

nothing relevant :/

Nextcloud log

nothing relevant :/

Browser log

nothing relevant :/

The text was updated successfully, but these errors were encountered:

Tie-fighter · 2021-12-14T10:34:45Z

Sorry for being vague... I haven't figured out what triggers it yet...

szaimen · 2021-12-14T10:39:07Z

Hi there, the issue was due to nextcloud/desktop#4016. Should be fixed in the next desktop release

PhilippSchlesinger · 2021-12-17T12:42:58Z

It is good to see the root issue will be fixed by nextcloud/desktop#4016 in the next desktop release.

Yet server side files already got corrupted timestamps.
As previous version of a single affected file contains valid data with valid timestamp, restoring this version mitigates impacts of this issue.
To restore all files some view like described in #30258 (comment) would really help.
e. g. show all files affected by this issue and be able to restore all at once.

Tie-fighter · 2021-12-17T13:08:25Z

I am using ZFS (which I can wholeheartedly recommend), so rolling back was easy in my case.

Thanks for pointing out #30258 (comment) which looks promising too!

PhilippSchlesinger · 2021-12-17T13:22:02Z

ZFS sounds good, but is not available in a managed nextcloud environment. Also, we need to be able to only restore affected files as there have been other changes since. Am 17. Dezember 2021 14:08:35 MEZ schrieb Tie-fighter ***@***.***>:

I am using ZFS (which I can wholeheartedly recommend), so rolling back was easy in my case. Thanks for pointing out #30258 (comment) which looks promising too! -- Reply to this email directly or view it on GitHub: #30263 (comment) You are receiving this because you are subscribed to this thread. Message ID: ***@***.***>

-- Philipp Schlesinger

Tie-fighter · 2021-12-17T13:57:27Z

I understand.
imho especially in managed environments, a specialised filesystem like ZFS might (and should) be used. Maybe their support team can help?

For clarification: ZFS snapshots can be mounted (and are by default) so they can be accessed directly via the filesystem.
See: https://docs.oracle.com/cd/E36784_01/html/E36835/gbiqe.html

Finding affected files should be simple using find:
e.g. https://unix.stackexchange.com/questions/424319/how-to-find-files-based-on-timestamp

Restoring timestamps can be done using rsync:
e.g. https://stackoverflow.com/questions/21856085/how-to-sync-files-timestamps-only

This is of course all on filesystem level. Nextcloud will probably require a files:scan afterwards. Unsure what this affects saved file versions, etc.

That's how I would go about it. Please correct me if I am wrong somewhere.

PS: If you don't care about the correctness of the timestamp, you could also simply just touch the files.

simonspa · 2021-12-22T16:55:08Z

(just to add: there is also a Nextcloud app that allows you to browse ZFS snapshots directly: https://apps.nextcloud.com/apps/files_snapshots)

Tie-fighter · 2021-12-22T22:04:37Z

(just to add: there is also a Nextcloud app that allows you to browse ZFS snapshots directly: https://apps.nextcloud.com/apps/files_snapshots)

There is not! :O
installing intensifies

andriusr · 2021-12-27T17:53:16Z

Had the same issue (corrupted timestamps) on MacOS 10.14 (Mojave), desktop client 3.4.1. It seems that desktop client somehow corrupted timestamps on server side (running Debian) as well. Some files attribuites are 52 years back (for example, created 1970-01-01), some 82 years ahead (modifiend on 2106-02-07).
I think 3.4.1 should not be distributed until these issues are solved.

Tie-fighter · 2022-02-15T09:41:15Z

It seems like there is still an issue.
After removing the sync connection, deleting the files and adding the sync connection some 22k files still cannot be synced.
"Could not update metadata due to invalid modification..."

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Corrupted file timestamps #30263

Corrupted file timestamps #30263

Tie-fighter commented Dec 14, 2021

Tie-fighter commented Dec 14, 2021

szaimen commented Dec 14, 2021

PhilippSchlesinger commented Dec 17, 2021 •

edited

Loading

Tie-fighter commented Dec 17, 2021

PhilippSchlesinger commented Dec 17, 2021 via email

Tie-fighter commented Dec 17, 2021 •

edited

Loading

simonspa commented Dec 22, 2021

Tie-fighter commented Dec 22, 2021

andriusr commented Dec 27, 2021

Tie-fighter commented Feb 15, 2022 •

edited

Loading

Corrupted file timestamps #30263

Corrupted file timestamps #30263

Comments

Tie-fighter commented Dec 14, 2021

Steps to reproduce

Expected behaviour

Actual behaviour

Server configuration detail

Client configuration

Logs

Tie-fighter commented Dec 14, 2021

szaimen commented Dec 14, 2021

PhilippSchlesinger commented Dec 17, 2021 • edited Loading

Tie-fighter commented Dec 17, 2021

PhilippSchlesinger commented Dec 17, 2021 via email

Tie-fighter commented Dec 17, 2021 • edited Loading

simonspa commented Dec 22, 2021

Tie-fighter commented Dec 22, 2021

andriusr commented Dec 27, 2021

Tie-fighter commented Feb 15, 2022 • edited Loading

PhilippSchlesinger commented Dec 17, 2021 •

edited

Loading

Tie-fighter commented Dec 17, 2021 •

edited

Loading

Tie-fighter commented Feb 15, 2022 •

edited

Loading