Petit bug de sous_repertoire()
Découvert hier, un enchaînement tueur :
$demo = sous_repertoire(_DIR_TMP, 'demo_');
// $demo = 'tmp/demo_'
$bug = sous_repertoire($demo, 'potiron');
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.nbase = 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 ?