Recherche avancée

Sur d’autres sites (8141)

• Anomalie #4245 (Fermé) : Petit bug de sous_repertoire()

  11 décembre 2018

  Découvert hier, un enchaînement tueur :

  <span class="CodeRay"><span class="local-variable">$demo</span> = sous_repertoire(_DIR_TMP, <span class="string"><span class="delimiter">'</span><span class="content">demo_</span><span class="delimiter">'</span></span>);
  <span class="comment">// $demo = 'tmp/demo_'</span>
  <span class="local-variable">$bug</span> = sous_repertoire(<span class="local-variable">$demo</span>, <span class="string"><span class="delimiter">'</span><span class="content">potiron</span><span class="delimiter">'</span></span>);
  </span>
  Télécharger

  Le système a rencontré une erreur lors de l’écriture du fichier tmp/demo/potiron/.plat.

  En fait, lors de l’appel de sous_repertoire($base, $subdir), la fonction vire les / et _ finaux de $base (mais pas le _ final éventuel de $subdir).
  Il se retrouve ici à vouloir créer le répertoire tmp/demo/potiron au lieu de tmp/demo_/potiron et n’y arrive pas, vu que le répertoire parent (demo) n’existe pas.

  Histoire¶

  Après quelques fouilles archéologiques, il se trouve que le problème survient probablement avec r8196 qui refactore différemment le code de r6395 :
  - 6395 fil@rezo.n     if (!preg_match(',[/_]$,', $base)) $base .= '/';
  - 8196 esj@rezo.n     if (preg_match(',[/_]$,', $base)) $base = substr($base,0,-1);
  - 16035 fil@rezo.n     $base = rtrim($base, '/_');

  Le tout devait être, je suppose, pour prendre en compte les excentriques répertoires "plats" (dépendants maintenant de la présence de la constante _CREER_DIR_PLAT).

  Corrections¶

  Plusieurs corrections possibles :
  - A) virer la constante _CREER_DIR_PLAT et ses actions, et le rtrim de ce souligné (on est en 2018…).
  - B) simplement appliquer le rtrim du souligné si _CREER_DIR_PLAT est présent (ça corrige pas le bug que $subdir n’aurait alors pas ce rtrim non plus !)
  - C) B + corriger le rtrim pour $subdir de la même manière.

  Je suis partisan de A) sur le trunk, et B) ou C) sur 3.2 et 3.1.

  Des avis ?

• Anomalie #3236 (Nouveau) : opendir et readdir

  27 juin 2014, par Ybbet SPIP

  Hello,

  Juste pour signaler qu’il y a une erreur d’écriture (par conseillé en tout cas) sur :
  - SPIP 3.1 :
  http://core.spip.org/projects/spip/repository/entry/spip/ecrire/public/composer.php#L475
  http://core.spip.org/projects/spip/repository/entry/spip/ecrire/inc/install.php#L348

  - SPIP 3.0 :
  http://core.spip.org/projects/spip/repository/entry/branches/spip-3.0/ecrire/public/composer.php#L392
  http://core.spip.org/projects/spip/repository/entry/branches/spip-3.0/ecrire/inc/install.php#L341

  - SPIP 2.1 :
  http://core.spip.org/projects/spip/repository/entry/branches/spip-2.1/ecrire/public/composer.php#L392
  http://core.spip.org/projects/spip/repository/entry/branches/spip-2.1/ecrire/inc/install.php#L272

  - SPIP 2.0 : http://core.spip.org/projects/spip/repository/entry/branches/spip-2.0/ecrire/public/composer.php#L403

  On a
  

  while ($f = readdir($d))
  

  Au lieu de
  

  while (($f = readdir($d)) !== false)
  

  
  Ecriture adoptée partout ailleurs dans le core de SPIP.

• Anomalie #3697 : Bug svn10000 SPIP 3

  14 février 2016, par MiKaël Navarro

  Cependant je m’étonne que cette erreur là « remplissent les logs du serveur Web », d’autant que l’erreur n’est pas critique.
  Normalement le if ($dir = opendir(...)) n’entre pas dans le if si opendir retourne false. Par contre, oui ça créait une erreur PHP si le dossier n’existait pas, mais qui ne devrait pas perturber il me semble la suite du processus de mise à jour. Je n’ai pas été vérifier cependant.

  Effectivement le if ($dir = opendir(...)) n’entre pas dans le if si opendir retourne false, mais ce n’est pas le code que j’ai dans l’archive spip-3.1.zip (r22707 aujourd’hui en date du 6 janvier), au lieu de ça j’ai seulement (sans le if) :
  

  $dir = opendir($base) ;
  while (($f = readdir($dir)) !== false) 
  ...
  

  De plus je suis d’accord, ce n’est pas une Erreur mais un simple Warning que l’on retrouve dans /var/log/nginx/error.log :
  

  2016/02/14 12:36:04 [error] 1141#0 : *197 FastCGI sent in stderr : "PHP message : PHP Warning :  opendir(baddir/) : failed to open dir : No such file or directory in /home/mickey/public_html/test-opendir.php on line 2
  PHP message : PHP Warning :  readdir() expects parameter 1 to be resource, boolean given in /home/mickey/public_html/test-opendir.php on line 3" while reading response header from upstream, client : 127.0.0.1, server : localhost, request : "GET / mickey/test-opendir.php HTTP/1.1", upstream : "fastcgi ://unix :/var/run/php5-fpm.sock :", host : "localhost" 
  

  
  Ensuite le test while (($f = readdir($dir)) !== false) rentre dans une boucle infinie et c’est avec ça que j’ai créé un log de plus de 2Go !

  D’après les commit, je vois que c’était déjà corrigé dans la version SVN, mais un test supplémentaire mange pas de pain ça sera plus robuste et évitera l’écriture d’un Warning dans les logs pour rien :)

  En tout cas merci pour votre réactivité.