plg a écrit:

Implémenté dans la version 13.b de extension:923

J'ai fait pas mal de tests MAIS je recommande solennellement de faire une sauvegarde des répertoires "_data" et "upload".

Merci beaucoup ! Entre temps, j'ai réalisé que mon hébergeur conservait une sauvegarde de l'espace de fichiers sur 15 jours, et j'ai pu récupérer mon dossier upload. Il n'y a finalement qu'un album à re-uploader.

PB a écrit:

[...] le mécanisme de restauration "dégradée" évoqué serait vraiment le bienvenu pour palier le problène dans l'immédiat !

Implémenté dans la version 13.b de extension:923

J'ai fait pas mal de tests MAIS je recommande solennellement de faire une sauvegarde des répertoires "_data" et "upload".

plg a écrit:

On a pensé à un mécanisme de restauration "dégradée" à partir de la taille multiple la plus grande disponible dans le cache. Par exemple si la taille Large existe, alors on la copie comme étant la nouvelle originale. Pour ceux qui n'ont pas de sauvegarde, ce serait mieux que rien. Si on a de la demande, on implémentera quelque chose comme ça.

Bonjour Pierrick.

J'ai découvert ce bug en passant à la version 13.4 aujourd'hui et surtout que notre galerie familiale en a fait les frais (1778 fichiers manquants). Je n'ai pas de sauvegarde du dossier "uploads" et, même si les différents utilisateurs de la galerie doivent bien avoir les images originales sur leur disque local, le mécanisme de restauration "dégradée" évoqué serait vraiment le bienvenu pour palier le problène dans l'immédiat !

Bien cordailement.

RM25 a écrit:

Normalement, lorsque l'on supprime un lien symbolique [...] Savez-vous ce qu'a exactement fait cette ligne de code obsolete.list ?

Sauf que c'est une hypothèse de départ erronée. Voici la fonction qui fait ce que le obsolete.list lui dit de faire :

  static function process_obsolete_list($file)
  {
    if (file_exists(PHPWG_ROOT_PATH.$file)
      and $old_files = file(PHPWG_ROOT_PATH.$file, FILE_IGNORE_NEW_LINES)
      and !empty($old_files))
    {
      $old_files[] = $file;
      foreach($old_files as $old_file)
      {
        $path = PHPWG_ROOT_PATH.$old_file;
        if (is_file($path))
        {
          @unlink($path);
        }
        elseif (is_dir($path))
        {
          deltree($path, PHPWG_ROOT_PATH.'_trash');
        }
      }
    }
  }

Je suppose que pour PHP, ton lien symbolique est un répertoire (is_dir) car cela pointe vers un répertoire. Donc ça fait un deltree et toute l'arborescence est supprimée.

On a prévu d'ajouter un garde-fou à ce niveau là pour éviter de supprimer certains répertoires : ., upload, galleries, _data, local

RM25 a écrit:

Sans savoir comment en être sûr (je ne trouve pas de fichier log enregistrant les dates de mise à jour)

J'ai prévu d'ajouter une trace dans les logs. Il faut qu'on puisse avoir un historique des mises à jours. On l'a pour les mises à jour "majeures" grâce à la table piwigo_upgrade mais rien sur les mises à jour mineurs. Eventuellement on peut essayer de regarder quelle est la date d'un fichier comme include/constants.php (présent dans chaque mise à jour car contenant le numéro de version de Piwigo) mais ce n'est pas très fiable et impossible de remonter dans le temps. On saura juste pour la date de dernière mise à jour.

Merci ddtddt pour ta réponse rapide. Mon dossier contenant mes photos est intact.

Je viens de lire post:236328 concernant l'historique de ce bug. Comme boge90, mon dossier upload est un lien symbolique vers un autre dossier situé sur un disque RAID indépendant du disque sur lequel est installé Piwigo (/var/www/piwigo). Mon lien symbolique appartient à root:root, pas à www-data:www-data. Seul le dossier cible appartient à www-data:www-data.

Normalement, lorsque l'on supprime un lien symbolique, le dossier de destination n'est pas supprimé. Pourquoi donc le lien et le dossier de boge90 ont-ils été supprimé ? La commande rm upload ne supprime que le lien : pas le dossier cible ! Savez-vous ce qu'a exactement fait cette ligne de code obsolete.list ?
Dans mon cas, comme le lien appartient à root:root, l'utilisateur www-data n'aurait en plus en théorie pas pu le supprimer.

Sans savoir comment en être sûr (je ne trouve pas de fichier log enregistrant les dates de mise à jour), je n'ai peut-être tout simplement pas fait face à ce bug en mettant à jour avant le 8/12 (car je n'ai pas consulté ma galerie entre le 5 et le 17/12).

Bonsoir à tous,

J'avais mis à jour mon piwigo autohebergé de la 13.2 à 13.3 sans trop regarder le forum ; et en lisant ce post, je constate que j'ai peut-être sauvé mes photos de la suppression à venir lire le forum avant de mettre à jour vers la 13.4 !

Pourriez-vous m'expliquer ce que Piwigo peut supprimer en passant de la 13.3 à 13.4 ? Les photos dans le dossier Galerie ? dans upload ? Les deux ? uniquement les photos du cache ? Où sont-elles stocker dans le dossier piwigo ?

Par précaution, j'ai bloqué les droits en écriture de www-data afin de protéger mes photos dans upload. Cependant, j'aimerais être sûr que toutes mes photos original sont toujours bien dans ce dossier et qu'aucune par exemple n'est déplacé temporairement dans un autre dossier dit "cache" !?

Quoi qu'il en soit, pour le moment, je ne touche plus rien et je ne mets surtout pas à jour avant d'avoir fait toutes mes sauvegardes !

Avec tous mes remerciements

tomdieu a écrit:

Call to undefined function fs_quick_check()

C'est une nouvelle fonction dans Piwigo 13.4.0. Le fichier qui l'appelle (admin/intro.php) et le fichier qui la définit (admin/include/functions.php) sont présents dans l'archive de mise à jour. Si tu as l'un sans l'autre, c'est qu'il y a eu un problème à l'application de la mise à jour.

Avant de faire la mise à jour 13.x_to_13.4.0.zip (en bas de page) il serait intéressant d'analyser le contenu de ton Piwigo. Va directement sur la page admin.php?page=plugins (sans passer par le tableau de bord) et installes/actives/configures le plugin extension:844 : il va détecter si des fichiers de Piwigo ne sont pas tels qu'attendus.