[résolu/contourné] problème avec la corbeille de Nextcloud

jajaX · 15 sept. 2020

salut,

j'ai un soucis, depuis un moment avec la corbeille de nextcloud.

quand je veux y aller, j'ai message suivant =>

Ce répertoire est indisponible, merci de consulter les journaux ou de contacter votre administrateur

trace dans le log :

Fatal	webdav	Doctrine\DBAL\Exception\DriverException: An exception occurred while executing 'SELECT `id`, `timestamp`, `location` FROM `oc_files_trash` WHERE `user`=?' with params ["jaja"]: SQLSTATE[HY000]: General error: 1709 Index column size too large. The maximum column size is 767 bytes.

    /var/www/owncloud/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/DBALException.php - line 169:

    Doctrine\DBAL\Driver\AbstractMySQLDriver->convertException()

    /var/www/owncloud/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/DBALException.php - line 145:

    Doctrine\DBAL\DBALException::wrapException()

    /var/www/owncloud/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Statement.php - line 162:

    Doctrine\DBAL\DBALException::driverExceptionDuringQuery()

    /var/www/owncloud/lib/private/legacy/OC_DB_StatementWrapper.php - line 72:

    Doctrine\DBAL\Statement->execute()

    /var/www/owncloud/apps/files_trashbin/lib/Trashbin.php - line 129:

    OC_DB_StatementWrapper->execute()

    /var/www/owncloud/apps/files_trashbin/lib/Helper.php - line 64:

    OCA\Files_Trashbin\Trashbin::getLocations()

    /var/www/owncloud/apps/files_trashbin/lib/Trash/LegacyTrashBackend.php - line 74:

    OCA\Files_Trashbin\Helper::getTrashFiles()

    /var/www/owncloud/apps/files_trashbin/lib/Trash/TrashManager.php - line 48:

    OCA\Files_Trashbin\Trash\LegacyTrashBackend->listTrashRoot()

    <<closure>>

    OCA\Files_Trashbin\Trash\TrashManager->OCA\Files_Trashbin\Trash\{closure}("*** sensiti ... *")

    /var/www/owncloud/apps/files_trashbin/lib/Trash/TrashManager.php - line 49:

    array_reduce()

    /var/www/owncloud/apps/files_trashbin/lib/Sabre/TrashRoot.php - line 72:

    OCA\Files_Trashbin\Trash\TrashManager->listTrashRoot()

    /var/www/owncloud/3rdparty/sabre/dav/lib/DAV/Tree.php - line 204:

    OCA\Files_Trashbin\Sabre\TrashRoot->getChildren()

    /var/www/owncloud/3rdparty/sabre/dav/lib/DAV/Server.php - line 905:

    Sabre\DAV\Tree->getChildren()

    /var/www/owncloud/3rdparty/sabre/dav/lib/DAV/Server.php - line 987:

    Sabre\DAV\Server->generatePathNodes()

    /var/www/owncloud/3rdparty/sabre/dav/lib/DAV/Server.php - line 1678:

    Sabre\DAV\Server->getPropertiesIteratorForPath()

    /var/www/owncloud/3rdparty/sabre/dav/lib/DAV/Server.php - line 1661:

    Sabre\DAV\Server->writeMultiStatus()

    /var/www/owncloud/3rdparty/sabre/dav/lib/DAV/CorePlugin.php - line 363:

    Sabre\DAV\Server->generateMultiStatus()

    /var/www/owncloud/3rdparty/sabre/event/lib/WildcardEmitterTrait.php - line 89:

    Sabre\DAV\CorePlugin->httpPropFind()

    /var/www/owncloud/3rdparty/sabre/dav/lib/DAV/Server.php - line 474:

    Sabre\DAV\Server->emit()

    /var/www/owncloud/3rdparty/sabre/dav/lib/DAV/Server.php - line 251:

    Sabre\DAV\Server->invokeMethod()

    /var/www/owncloud/3rdparty/sabre/dav/lib/DAV/Server.php - line 319:

    Sabre\DAV\Server->start()

    /var/www/owncloud/apps/dav/lib/Server.php - line 320:

    Sabre\DAV\Server->exec()

    /var/www/owncloud/apps/dav/appinfo/v2/remote.php - line 35:

    OCA\DAV\Server->exec()

    /var/www/owncloud/remote.php - line 167:

    require_once("/var/www/ow ... p")

Causé parDoctrine\DBAL\Driver\PDOException: SQLSTATE[HY000]: General error: 1709 Index column size too large. The maximum column size is 767 bytes.

    /var/www/owncloud/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Statement.php - line 153:

    Doctrine\DBAL\Driver\PDOStatement->execute()

    /var/www/owncloud/lib/private/legacy/OC_DB_StatementWrapper.php - line 72:

    Doctrine\DBAL\Statement->execute()

    /var/www/owncloud/apps/files_trashbin/lib/Trashbin.php - line 129:

    OC_DB_StatementWrapper->execute()

    /var/www/owncloud/apps/files_trashbin/lib/Helper.php - line 64:

    OCA\Files_Trashbin\Trashbin::getLocations()

    /var/www/owncloud/apps/files_trashbin/lib/Trash/LegacyTrashBackend.php - line 74:

    OCA\Files_Trashbin\Helper::getTrashFiles()

    /var/www/owncloud/apps/files_trashbin/lib/Trash/TrashManager.php - line 48:

    OCA\Files_Trashbin\Trash\LegacyTrashBackend->listTrashRoot()

    <<closure>>

    OCA\Files_Trashbin\Trash\TrashManager->OCA\Files_Trashbin\Trash\{closure}("*** sensiti ... *")

    /var/www/owncloud/apps/files_trashbin/lib/Trash/TrashManager.php - line 49:

    array_reduce()

    /var/www/owncloud/apps/files_trashbin/lib/Sabre/TrashRoot.php - line 72:

    OCA\Files_Trashbin\Trash\TrashManager->listTrashRoot()

    /var/www/owncloud/3rdparty/sabre/dav/lib/DAV/Tree.php - line 204:

    OCA\Files_Trashbin\Sabre\TrashRoot->getChildren()

    /var/www/owncloud/3rdparty/sabre/dav/lib/DAV/Server.php - line 905:

    Sabre\DAV\Tree->getChildren()

    /var/www/owncloud/3rdparty/sabre/dav/lib/DAV/Server.php - line 987:

    Sabre\DAV\Server->generatePathNodes()

    /var/www/owncloud/3rdparty/sabre/dav/lib/DAV/Server.php - line 1678:

    Sabre\DAV\Server->getPropertiesIteratorForPath()

    /var/www/owncloud/3rdparty/sabre/dav/lib/DAV/Server.php - line 1661:

    Sabre\DAV\Server->writeMultiStatus()

    /var/www/owncloud/3rdparty/sabre/dav/lib/DAV/CorePlugin.php - line 363:

    Sabre\DAV\Server->generateMultiStatus()

    /var/www/owncloud/3rdparty/sabre/event/lib/WildcardEmitterTrait.php - line 89:

    Sabre\DAV\CorePlugin->httpPropFind()

    /var/www/owncloud/3rdparty/sabre/dav/lib/DAV/Server.php - line 474:

    Sabre\DAV\Server->emit()

    /var/www/owncloud/3rdparty/sabre/dav/lib/DAV/Server.php - line 251:

    Sabre\DAV\Server->invokeMethod()

    /var/www/owncloud/3rdparty/sabre/dav/lib/DAV/Server.php - line 319:

    Sabre\DAV\Server->start()

    /var/www/owncloud/apps/dav/lib/Server.php - line 320:

    Sabre\DAV\Server->exec()

    /var/www/owncloud/apps/dav/appinfo/v2/remote.php - line 35:

    OCA\DAV\Server->exec()

    /var/www/owncloud/remote.php - line 167:

    require_once("/var/www/ow ... p")

Causé parPDOException: SQLSTATE[HY000]: General error: 1709 Index column size too large. The maximum column size is 767 bytes.

    /var/www/owncloud/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOStatement.php - line 117:

    PDOStatement->execute()

    /var/www/owncloud/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Statement.php - line 153:

    Doctrine\DBAL\Driver\PDOStatement->execute()

    /var/www/owncloud/lib/private/legacy/OC_DB_StatementWrapper.php - line 72:

    Doctrine\DBAL\Statement->execute()

    /var/www/owncloud/apps/files_trashbin/lib/Trashbin.php - line 129:

    OC_DB_StatementWrapper->execute()

    /var/www/owncloud/apps/files_trashbin/lib/Helper.php - line 64:

    OCA\Files_Trashbin\Trashbin::getLocations()

    /var/www/owncloud/apps/files_trashbin/lib/Trash/LegacyTrashBackend.php - line 74:

    OCA\Files_Trashbin\Helper::getTrashFiles()

    /var/www/owncloud/apps/files_trashbin/lib/Trash/TrashManager.php - line 48:

    OCA\Files_Trashbin\Trash\LegacyTrashBackend->listTrashRoot()

    <<closure>>

    OCA\Files_Trashbin\Trash\TrashManager->OCA\Files_Trashbin\Trash\{closure}("*** sensiti ... *")

    /var/www/owncloud/apps/files_trashbin/lib/Trash/TrashManager.php - line 49:

    array_reduce()

    /var/www/owncloud/apps/files_trashbin/lib/Sabre/TrashRoot.php - line 72:

    OCA\Files_Trashbin\Trash\TrashManager->listTrashRoot()

    /var/www/owncloud/3rdparty/sabre/dav/lib/DAV/Tree.php - line 204:

    OCA\Files_Trashbin\Sabre\TrashRoot->getChildren()

    /var/www/owncloud/3rdparty/sabre/dav/lib/DAV/Server.php - line 905:

    Sabre\DAV\Tree->getChildren()

    /var/www/owncloud/3rdparty/sabre/dav/lib/DAV/Server.php - line 987:

    Sabre\DAV\Server->generatePathNodes()

    /var/www/owncloud/3rdparty/sabre/dav/lib/DAV/Server.php - line 1678:

    Sabre\DAV\Server->getPropertiesIteratorForPath()

    /var/www/owncloud/3rdparty/sabre/dav/lib/DAV/Server.php - line 1661:

    Sabre\DAV\Server->writeMultiStatus()

    /var/www/owncloud/3rdparty/sabre/dav/lib/DAV/CorePlugin.php - line 363:

    Sabre\DAV\Server->generateMultiStatus()

    /var/www/owncloud/3rdparty/sabre/event/lib/WildcardEmitterTrait.php - line 89:

    Sabre\DAV\CorePlugin->httpPropFind()

    /var/www/owncloud/3rdparty/sabre/dav/lib/DAV/Server.php - line 474:

    Sabre\DAV\Server->emit()

    /var/www/owncloud/3rdparty/sabre/dav/lib/DAV/Server.php - line 251:

    Sabre\DAV\Server->invokeMethod()

    /var/www/owncloud/3rdparty/sabre/dav/lib/DAV/Server.php - line 319:

    Sabre\DAV\Server->start()

    /var/www/owncloud/apps/dav/lib/Server.php - line 320:

    Sabre\DAV\Server->exec()

    /var/www/owncloud/apps/dav/appinfo/v2/remote.php - line 35:

    OCA\DAV\Server->exec()

    /var/www/owncloud/remote.php - line 167:

    require_once("/var/www/ow ... p")

le dossier "owncloud" date de mon ancienne installation de owncloud. j'ai migré vers nextcloud depuis, sans modifier le chemin.

quand je vais voir la table dans phpmyadmin, il me sort :

#1709 - Index column size too large. The maximum column size is 767 bytes.

le problème est arrivé comme ça. le pire est que les fichers se suppriment bien. je peux les voir dans mon dossier data (dans le .../jaja/files_thrashbin/files).

ce n'est pas un problème de place.

j'avais le soucis avant de faire la maj de la 18.04 vers 20.04 (de mémoire)

infos :
kubuntu 20.04 (migré de la 18.04)
Nextcloud 19.03

version de php :

php -v
PHP 7.4.3 (cli) (built: May 26 2020 12:24:22) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
    with Zend OPcache v7.4.3, Copyright (c), by Zend Technologies

j'ai épluché les forums, testé quelques "trucs" mais sans succés...

une idée ?

Bbruno · 15 sept. 2020

Bonjour,

Ça ressemble à une mise à niveau de Nextcloud qui n'a pas été correctement menée.
En supposant que tu utilises le module PHP d'Apache et que les scripts PHP sont exécutés par www-data, donne le retour de :

cd /var/www/owncloud/
sudo -u www-data php occ upgrade

jajaX · 15 sept. 2020

la réponse ne va pas beaucoup aider, je pense :lol:

sudo -u www-data php occ upgrade
[sudo] Mot de passe de server : 
Nextcloud is already latest version

edit : un "repair" donne ça =>

sudo -u www-data php occ maintenance:repair
 - Repair MySQL collation
     - All tables already have the correct collation -> nothing to do
 - Repair mime types
 - Clean tags and favorites
     - 0 tags of deleted users have been removed.
     - 0 tags for delete files have been removed.
     - 0 tag entries for deleted tags have been removed.
     - 0 tags with no entries have been removed.
 - Repair invalid shares
 - Move .step file of updater to backup location
 - Fix potential broken mount points
     - No mounts updated
 - Add log rotate job
 - Clear frontend caches
     - Image cache cleared
     - SCSS cache cleared
     - JS cache cleared
 - Clear every generated avatar on major updates
 - Add preview background cleanup job
 - Queue a one-time job to cleanup old backups of the updater
 - Cleanup invalid photocache files for carddav
 - Add background job to cleanup login flow v2 tokens
 - Remove potentially over exposing share links
     - No need to remove link shares.
 - Clear access cache of projects
 - Reset generated avatar flag
 - Add read permissions for existing announcements
    0 [->--------------------------]
 - Deduplicate shared bookmark folders
     - Removed 0 duplicate shares
 - Remove superfluous shared bookmark folders
     - Removed 0 superfluous shares
 - Remove orphaned bookmark shares
     - Removed 0 orphaned shares
     - Removed 0 orphaned public links
 - Remove orphaned bookmark tree items
     - Removed 0 orphaned bookmarks
     - Removed 30 orphaned bookmark folders
 - Update bookmark group shares
     - Removed 0 users and added 0 users to 0 groups
     - Removed 0 shares
 - Update name of the stored view
 - Fix component of birthday calendars
     - 4 birthday calendars updated.
 - Regenerating birthday calendars to use new icons and fix old birthday events without year
     - Repair step already executed
 - Fix broken values of calendar objects
    0 [----->----------------------]
 - Registering building of calendar search index as background job
     - Repair step already executed
 - Registering background jobs to update cache for webcal calendars
     - Added 0 background jobs to update webcal calendars
 - Registering building of calendar reminder index as background job
     - Repair step already executed
 - Clean up orphan event and contact data
     - 0 events without a calendar have been cleaned up
     - 0 properties without an events have been cleaned up
     - 0 changes without a calendar have been cleaned up
     - 0 cached events without a calendar subscription have been cleaned up
     - 0 changes without a calendar subscription have been cleaned up
     - 0 contacts without an addressbook have been cleaned up
     - 0 properties without a contact have been cleaned up
     - 0 changes without an addressbook have been cleaned up
 - Remove activity entries of private events
     - Removed 0 activity entries
 - Write default encryption module configuration to the database
 - Copy default images to the app data directory
     - Icon %s already exists
     - Icon %s already exists
     - Icon %s already exists
 - Fix the share type of guest shares when migrating from ownCloud
 - Copy the share password into the dedicated column
 - Set existing shares as accepted
 - Purify and migrate collected mail addresses
    0 [--------->------------------]
 - Insert background jobs for all accounts
 10/10 [============================] 100%
 - Make Mail itinerary extractor executable
 - Migrate Mail provisioning config from config.php to the database
     - No old config found
 - Create or update provisioned Mail accounts
     - No Mail provisioning config set
 - Migrate binary status into separate boolean fields
 - Clean up meta table
 - Update OAuth token expiration times
 - Migrate legacy conversation reading states
    1 [============================]
 - Check the installation of the Social app.
 - Create help command
 - Invalidate access cache for projects conversation provider
     - Invalidation not required
 - Switches from default updater server to the customer one if a valid subscription is available
     - Repair step already executed
 - Add background job to check for backup codes
 - Populating added database structures for workflows

Bbruno · 15 sept. 2020

Bizarre cela ne ressort pas l"erreur MYSQL.
Est-ce que tu peux donner le retour de cette requête SQL :

SHOW TABLE STATUS FROM nextcloud WHERE Name='oc_files_trash';

en remplaçant nextcloud par le nom de la base de données

jajaX · 15 sept. 2020

bruno a écritBizarre cela ne ressort pas l"erreur MYSQL.
Est-ce que tu peux donner le retour de cette requête SQL :

SHOW TABLE STATUS FROM nextcloud WHERE Name='oc_files_trash';

en remplaçant nextcloud par le nom de la base de données

voici la réponse :

Warning: #1709 Index column size too large. The maximum column size is 767 bytes.

Bbruno · 16 sept. 2020

Et m****, on ne peut pas voir à cause de cette erreur.
Essaie cette requête :

ALTER TABLE nextcloud.oc_files_trash ROW_FORMAT=COMPRESSED;

en remplaçant nextcloud par le nom de la base de données.

Ou en cas d’erreur :

ALTER TABLE nextcloud.oc_files_trash ROW_FORMAT=DYNAMIC;

jajaX · 16 sept. 2020

salut,

réponse de la première requête =>

Erreur

Requête SQL :

ALTER TABLE owncloud.oc_files_trash ROW_FORMAT=COMPRESSED

MySQL a répondu : Documentation
#1709 - Index column size too large. The maximum column size is 767 bytes.

réponse de la seconde requête =>

Erreur

Requête SQL :

ALTER TABLE owncloud.oc_files_trash ROW_FORMAT=DYNAMIC

MySQL a répondu : Documentation
#1709 - Index column size too large. The maximum column size is 767 bytes.

même réponse pour les 2 donc.

voici d'autres informations par rapport à cette table oc_files_thash qui pose problème =>

il faudrait qu'un autre utilisateur de nextcloud compare avec son installation pour savoir s'ils ont les mêmes paramètres que les miens. car je pense que le problème est un détails

Bbruno · 16 sept. 2020

Le problème c'est l'option ROW FORMAT de la table qui est erronée.
https://community.pivotal.io/s/article/Apps-are-down-due-to-the-Maximum-Column-Size-is-767-bytes-Constraint-in-MySQL?language=en_US
On le voit bien sur ta copie d'écran de phpmyadmin.

Comme on n'arrive pas à régler cela avec une reque SQL, il va fallloir récréer la table :
- tu exportes ta table oc_files_trash au format SQL ;
- tu modifies le fichier .sql obtenu en t'assurant que la partie CREATE TABLE corresponde à ceci :

DROP TABLE IF EXISTS `oc_files_trash`;
CREATE TABLE `oc_files_trash` (
  `auto_id` int(11) NOT NULL AUTO_INCREMENT,
  `id` varchar(250) COLLATE utf8mb4_bin NOT NULL DEFAULT '',
  `user` varchar(64) COLLATE utf8mb4_bin NOT NULL DEFAULT '',
  `timestamp` varchar(12) COLLATE utf8mb4_bin NOT NULL DEFAULT '',
  `location` varchar(512) COLLATE utf8mb4_bin NOT NULL DEFAULT '',
  `type` varchar(4) COLLATE utf8mb4_bin DEFAULT NULL,
  `mime` varchar(255) COLLATE utf8mb4_bin DEFAULT NULL,
  PRIMARY KEY (`auto_id`),
  KEY `id_index` (`id`),
  KEY `timestamp_index` (`timestamp`),
  KEY `user_index` (`user`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin ROW_FORMAT=COMPRESSED;

- tu supprimes la table oc_files_trash ;
- tu la recrées en important ton fichier SQL dans phpmyadmin ou en le sourçant avec une commande mysql.

jajaX · 16 sept. 2020

ok, mais l'exportation ne fonctionne pas. pour preuve, le contenu du fichier =>

-- phpMyAdmin SQL Dump
-- version 4.9.5deb2
-- https://www.phpmyadmin.net/
--
-- Hôte : localhost:3306
-- Généré le : mer. 16 sep. 2020 à 13:03
-- Version du serveur :  8.0.21-0ubuntu0.20.04.4
-- Version de PHP : 7.4.3

SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO";
SET AUTOCOMMIT = 0;
START TRANSACTION;
SET time_zone = "+00:00";


/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8mb4 */;

--
-- Base de données : `owncloud`
--

-- --------------------------------------------------------

--
-- Structure de la table `oc_files_trash`
--
-- Erreur de lecture de structure pour la table owncloud.oc_files_trash : #1709 - Index column size too large. The maximum column size is 767 bytes.
-- Erreur de lecture des données pour la table owncloud.oc_files_trash : #1709 - Index column size too large. The maximum column size is 767 bytes.
COMMIT;

/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;
/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;

Bbruno · 16 sept. 2020

Là je ne sais pas trop…
D'après cette page :
http://mysql.rjweb.org/doc.php/limits#767_limit_in_innodb_indexes

   SET GLOBAL innodb_file_format=Barracuda;
   SET GLOBAL innodb_file_per_table=1;
   SET GLOBAL innodb_large_prefix=1;
   logout & login (to get the global values);
   ALTER TABLE owncloud.oc_files_trash ROW_FORMAT=DYNAMIC;

pourrait résoudre le problème.

Sinon il faudra effacer physiquement les fichiers de la corbeille et recréer un table vide avec ce que j'ai indiqué en #8.

En espérant que tu n'aies pas le même problème sur d'autres tables…

jajaX · 16 sept. 2020

ok, j'espère m'y prendre comme il faut. j'envoie les requêtes sql via phpmyadmin sur la table.

résultats =>

Erreur

Requête SQL :

SET GLOBAL innodb_file_format=Barracuda

MySQL a répondu : Documentation
#1193 - Variable système 'innodb_file_format' inconnue

SET GLOBAL innodb_file_per_table=1;

donne

 MySQL a retourné un résultat vide (c'est à dire aucune ligne). (traitement en 0.0005 seconde(s).)

Erreur

Requête SQL :

SET GLOBAL innodb_large_prefix=1

MySQL a répondu : Documentation
#1193 - Variable système 'innodb_large_prefix' inconnue

après déconnexion/reconnexion

Erreur

Requête SQL :

ALTER TABLE owncloud.oc_files_trash ROW_FORMAT=DYNAMIC

MySQL a répondu : Documentation
#1709 - Index column size too large. The maximum column size is 767 bytes.

après ces manips, j'ai déplacé les fichiers de la corbeille. redémarré les services apache2 et mysql, sans succés...

la suppression ne fonctionne pas non plus :

Erreur

Requête SQL :

DROP TABLE `oc_files_trash`

MySQL a répondu : Documentation
#1709 - Index column size too large. The maximum column size is 767 bytes.

bon, après sur la page que tu m'as donné, je peux voir les lignes suivantes :

⚈ Upgrade to 5.7.7/10.2.2 (or later) for a 3072 byte limit;

je suis en version 8.0.21 pour mysql et Mariadb n'est pas installé

⚈ Change 255 to 191 on the VARCHAR -- you lose any values longer than 191 characters (unlikely?);

j'ai essayé de changé la valeur sur "id" ou "mine" mais j'obtiens toujours l'erreur

⚈ ALTER .. CONVERT TO utf8 -- you lose Emoji and some of Chinese;

ok, mais je le fais sur quel paramètre ?

⚈ Use a "prefix" index -- you lose some of the performance benefits.

je ne comprends pas la phrase

Bbruno · 16 sept. 2020

Au temps pour mois ces options n'existent plus dans MySQL 8.0 (mais ces bugs sont censées être résolus dans cette version…)

Tu peux essayer de repasser en utf8 avec :

ALTER TABLE owncloud.oc_files_trash CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;

mais j'ai bien peur que la requête échoue avec toujours la même erreur.

Pour l'instant on tourne en rond et je ne sais pas si le problème a une solution :/

jajaX · 16 sept. 2020

perdu ! :lol: :lol: mieux en rire je crois....

voici le (même) résultat :

Requête SQL :

ALTER TABLE owncloud.oc_files_trash CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci

MySQL a répondu : Documentation
#1709 - Index column size too large. The maximum column size is 767 bytes.

j'avais vu un forum onwcloud, je vais y aller faire un tour. je vais aussi contacter le support de nextcloud...

Bbruno · 16 sept. 2020

Ok parce que là je n'ai plus d'idées.
On est dans la même situation qu'une base corrompue. La seule solution étant de supprimer la base et de restaurer avec la dernière sauvegarde.

jajaX · 16 sept. 2020

encore moi !

j'ai une piste !! à l'époque de owncloud, j'avais du faire ça.

la ligne avait fonctionné.

j'avais rajouté les 3 lignes dans le fichier "my.cnf" de ma config de mysql.

mais si je laisse activer ces 3 lignes, mon server mysql, plante. je me dois de commenter les 2 premières pour que ça passe.

c'est pas dans ce fichier là ?

Bbruno · 17 sept. 2020

Non, c'est justement ces manipulations qui auraient dû convertir proprement les tables en utf8mb4 et ajuster en même temps l'option ROW FORMAT.

J'ai regardé les forums nextcloud et les signalement de bogues. Il y a pas mal de problèmes similaires mais aucune solution qui n'ai déjà été tentée, il me semble.

jajaX · 17 sept. 2020

salut,

ok mais c'est le bon fichier que j'ai modifié ?

tu aurais un lien que je regarde stp.

jajaX · 15 oct. 2020

hello

encore moi avec mon soucis !!!

j'ai fait la mal vers la version 19.04 pensant que ça aller résoudre le problème => nada
du coup, j'ai changé mon canal de maj et fait la mise à jour vers la version 20.00 => nada

voulant prendre le taureau par les cornes, j'ai voulu supprimé la table qui pose problème, pensant que la fonction "repair" aller la réparer. mais la suppression ne fonctionne pas non plus...

donc, je vous sollicite pour avoir votre aide.

j'aimerais donc, pour ceux qui connaissent =>

- la requête pour supprimer la table fautive "oc_files_trash"
- la requête pour la recréer (à partir d'un système qui fonctionne)

merci par avance

edit : revoyant le post de Bruno, plus haut, je me suis dit que je pouvais le faire tout seul finalement.

perdu !!

-- phpMyAdmin SQL Dump
-- version 4.9.5deb2
-- https://www.phpmyadmin.net/
--
-- Hôte : localhost:3306
-- Généré le : jeu. 15 oct. 2020 à 15:53
-- Version du serveur :  8.0.21-0ubuntu0.20.04.4
-- Version de PHP : 7.4.3

SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO";
SET AUTOCOMMIT = 0;
START TRANSACTION;
SET time_zone = "+00:00";


/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8mb4 */;

--
-- Base de données : `owncloud`
--

-- --------------------------------------------------------

--
-- Structure de la table `oc_files_trash`
--
-- Erreur de lecture de structure pour la table owncloud.oc_files_trash : #1709 - Index column size too large. The maximum column size is 767 bytes.
-- Erreur de lecture des données pour la table owncloud.oc_files_trash : #1709 - Index column size too large. The maximum column size is 767 bytes.
COMMIT;

/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;
/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;

donc l'export de fonctionne pas non plus...

Bbruno · 15 oct. 2020

Comme je l'ai dit plus haut on est dans la situation d'une base corrompue, enfin au moins une table. Ce n'est a priori pas récupérable avec des commandes SQL.

Je te propose, sans aucune garantie, la manip suivante :
- arrêt du serveur MySQL :

sudo systemctl stop mysql

- déplacement des fichiers correspondant à la table en question (emplacement à vérifier et destination à adpter éventuellement) :

sudo mv /var/lib/mysql/owncloud/oc_file_trash.* /tmp/

- déplacement des fichiers d'index MySQL :

sudo mv /var/lib/mysql/ib_logfile* /tmp

- redémarrage du serveur MySQL :

sudo systemctl start mysql

Si le service redémarre sans erreurs, tu recrées la table oc_file_trash avec la requête indiquée en #8.

jajaX · 15 oct. 2020

ok, d'accord, merci déjà

je tente ça demain et je te tiens au courant