Fonction du core qui fait le ménage dans les plugins: preInstallUpdate / postInstallUpdate

Le répertoire resources avec le nettoyage c’est facile, ca flinguera les dépendances de tous les plugins avec du nodejs déjà, du sang du sang du sang :smiley:

1 « J'aime »

J’ai bien précisé « si on prend la logique de nettoyage des fichiers » :smiley:
j’essaie juste de comprendre « l’esprit » de tout ceci.

Parce qu’en termes de dépendances il y a plusieurs plugin qui clone un repo pour le copier dans les resources aussi, c’est pas juste nodejs; mais bref, on va me dire que j’ai ma réponse du coup :wink:

Oui oui, après on pourrait nous dire que resources ben justement c’est pas grave, ca va effacer les fichiers, ca sera une bonne occasion de mettre à jour les dépendances en auto … :speak_no_evil:

Bonjour @Loic

Avec -mtime/-atime, il vous restera à gérer la destruction d’un plugin fonctionnel dans le cas où le téléchargement du zip de la mise à jour se passe mal.

2 « J'aime »

Je suis d’accord, peut être vérifier qu’on a bien téléchargé le zip (via md5sum ? ) avant de nettoyer…

J’ai vérifié pour -mtime et -atime.
Seul -mtime semble correct.
La date d’accès au fichier n’est pas mise à jour :

/var/www/html/plugins/ash/plugin_info# stat info.json
  Fichier : info.json
   Taille : 603         Blocs : 8          Blocs d'E/S : 4096   fichier
Périphérique : b307h/45831d     Inœud : 43351       Liens : 1
Accès : (0775/-rwxrwxr-x)  UID : (   33/www-data)   GID : (   33/www-data)
 Accès : 2020-01-11 11:34:01.800999998 +0100
Modif. : 2020-05-11 23:19:22.945294359 +0200
Changt : 2020-05-19 03:12:52.818290397 +0200
  Créé : -

@Loic a raison avec -mtime.

il y a un contrôle de consistance dans l’ouverture du zip.

Ça dépends du fstab c’est une option au mount… peut être une différence entre les versions debian

Il y a bien un noatime dans le fstab de ma Smart !

LABEL=emlinux / ext4 errors=remount-ro,noatime,nodiratime  0 1
LABEL=emuserdata /media/boot vfat rw,user,sync,exec,dev,suid,uid=1000,gid=1000,dmask=000,fmask=111,iocharset=utf8  0 0

tmpfs        /tmp            tmpfs  defaults,size=256M                                       0 0
/swapfile1 none swap sw 0 0
tmpfs        /tmp/jeedom            tmpfs  defaults,size=128M                                       0 0

Donc find -atime impossible pour tous les Jeedoms.

:frowning:

Si tout bien compris après lecture de ce topic, il faut que tous les fichiers qu’un plugin ajoute pour son propre fonctionnement après installation soit ajouté dans le répertoire « data » à la racine du plugin.
Correct ?
Est-ce maintenant la norme officielle Jeedom ?

Merci à vous

Dans le répertoire data ou dans tout autre répertoire non officiel (3rdparty, 3rparty, desktop, mobile, core, docs, install, script, vendor et plugin_info )

Je ne sais pas. Je ne fais pas partie de l’équipe Jeedom. Loic ne répond plus et je n’ai pas vu de com la-dessus

D’après mon test ce code va pas laisser grand chose dans les dossiers des p dalugins. Même l’api dans 3rdparty est sévèrement nettoyé.

Oui, mais le plugin qui s’installe après devrait tout ré-installer.

pas très grave si on re-télécharge le .zip du plugin à partir du market et qu’on le remet ensuite (tant qu’on convient d’un nomage à protéger par exemple…)

par contre, ca serait bien de vérifier le .zip avant de supprimer le contenu du plugin… imaginons une situation comme aujourd’hui avec un market qui bug… on vire le contenu avant le téléchargement du zip et la vérification de celui-ci…

OK.
Merci pour la précision.
Je croyais que le nettoyage intervenait après l’install.

Il faudrait juste déplacer l’appel de la fonction aussitôt après l’ouverture du Zip ZipArchive->open qui retourne TRUE si la consistance du zip est OK:

$res = $zip->open($tmp);
  if ($res === TRUE) {
       // Faire le ménage ICI
    if (!$zip->extractTo($cibDir . '/'))

ou check md5… (ou sha je suis pas raciste)

éviter la fameuse erreur du zip trop petit sur le market…

Le zip trop petit avec son throw Exception est traité au dessus de zip->open

J’ai fait ce PR: https://github.com/jeedom/core/pull/1690 pour le déplacement de la fonction.

En plus du nettoyage fait avant l’installation, après installation du plugin, les répertoires doc et docs sont supprimés. La doc doit donc être obligatoirement extérieure au plugin.

if (file_exists(__DIR__ . '/../../plugins/' . $this->getLogicalId() . '/doc')) {
	shell_exec('sudo rm -rf ' . __DIR__ . '/../../plugins/' . $this->getLogicalId() . '/doc');
}
if (file_exists(__DIR__ . '/../../plugins/' . $this->getLogicalId() . '/docs')) {
	shell_exec('sudo rm -rf ' . __DIR__ . '/../../plugins/' . $this->getLogicalId() . '/docs');
}
1 « J'aime »

Non, pas obligatoire mais dans tous les cas le répertoire docs n’était et n’est jamais utilisé sur jeedom, uniquement sur github page.