11 How to fix the error invalid or negative modification date

Matthieu Gallien редактировал(а) эту страницу 2022-06-15 15:07:15 +02:00

Содержание

• 🐞 About the error "Could not update metadata due to invalid modified time"
• How to figure out if you have been affected by it
• ⚠️ Before you proceed
• 🔧 How to fix it
• Files stored on the server
• Files stored in Group Folders
• 👀 How to check if all files were fixed

🐞 About the error "Could not update metadata due to invalid modified time"

The bug was introduced in the Desktop client 3.4.0.

This bug is leading the client to loose the correct modification time of files and overwrite it with an invalid date (0 seconds since epoch). This will trigger the upload of those files to the server that might not check that the modification time is and accept invalid modification time.

There are two problems with that:

• the user is loosing the modification time metadata of files
• the desktop client sync engine does not work properly in that situation and desktop clients might be unable to sync anymore. They might try infinitely to sync those files because this invalid dates trigger continuous synchronization.

Those set of bugs in the desktop client might also lead to the desktop client pushing modification time in far future for those files affected by this bug.

How to figure out if you have been affected by it

• If your systems have been affected by the invalid metadata issue in desktop client 3.4.0, the error might be visible on the desktop client interface and in the logs: Could not update metadata due to invalid modified time.
• If you already had upgraded top a newer release, the error might be visible on the desktop client interface and in the logs: Cannot sync due to invalid modification time.
• You can find the affected files in your database using a SQL query:
  SELECT COUNT(*) FROM oc_filecache WHERE mtime < 86400;

⚠️ Before you proceed

1. Note that recovering the exact modification time requires restoring backups which may be impractical if the files have been modified already. These scripts therefore only fix the lack of a valid date and time (which breaks syncing) by setting a fixed, valid date and time. Syncing will happen again, but the original, correct date and time are lost. In most situations, this is sufficient.
2. You do not need to put the server in maintenance mode.
3. You do not need to make a backup of your database, however backups are always recommended as a regular practice.
4. Make sure to be running the latest desktop client.
5. Make sure to use the latest version of the scripts.

🔧 How to fix it

We provide the following scripts to help with the recovery of the server state.

Files stored on the server

1. Script for server side fixing of invalid dates (solvable_files.sh)
   • Copy the file to the nextcloud folder on the server.
   • chmod a+x solvable_files.sh
   • Call it with the following arguments:
     ./solvable_files.sh <path to storage folder without trailing /> <mysql|pgsql> <database host> <database user> <database password> <database name> <list|fix> <noscan|scan>
     • If you call it with the list argument: it will generate a list of the files with invalid modification date.
     • If you call it with the fix argument: it will fix all the files and the server database.
     • If you call it with the scan argument: it will automatically trigger a scan of each modified file.
     • As a last step it is necessary to scan the files on the storage (unless you used the scan argument):
       sudo -u www-data php <path to nextcloud install>/occ files:scan --all

Files stored in Group Folders

If you use the group folders feature, we provide the following scripts to help with the recovery of the files located in group folders:

1. Script to scan files in the group folders (scan_group_folders.sh)

   • Copy the file to the nextcloud folder on the server.
   • chmod a+x scan_group_folders.sh
   • Run the script:
     sudo -u <www-data|apache> ./scan_group_folders.sh

2. Script to fix the database state in case the affected files from group folders are in the trash bin or are old versioned files that may not have the correct state in the server database (fix_group_folders.sh)

   • Copy the file to the nextcloud folder on the server.
   • chmod a+x fix_group_folders.sh
   • Call it with the following arguments:
     ./fix_group_folders.sh <path to storage folder> <mysql|pgsql> <database host> <database user> <database password> <database name>

👀 How to check if all files were fixed

This script lists files that can not be fixed by the solvable_files.sh script:

1. Script to compare files found in the database with files found in on the server's file system and prints the diff (unsolvable_files.sh)
   • Copy the file to the nextcloud folder on the server.
   • chmod a+x unsolvable_files.sh
   • Call it with the following arguments:
     ./unsolvable_files.sh <data_dir> <mysql|pgsql> <db_host> <db_user> <db_pwd> <db_name>