[spip-dev] ?Probl?me de mise ? jour de base avec derni?re version CVS

Bonjour,

J'ai laissé se stabiliser le site RAforum qui focntionnait avec une version
CVS du 29/10. En local, je me retrouvait avec cette même version et je viens
de décider de passer à la CVS du jour.

Je fais comme d'hab, je charge les fichiers, supprime le inc_connect.php3...
Spip me demande gentiment d'identifier ma base, de donner mes coordonnées...
Et, ensuite, je me retrouve avec la mire de mise à jour de la base : soit !
Je fais le boulot... et me retrouve avec la mire ! Et ça boucle !

Dans la log, j'ai ce message

Nov 29 13:50:01 127.0.0.1 (pid 1720) Action admin: mise à niveau de
votre base MySQL
Nov 29 13:50:01 127.0.0.1 (pid 1720) echec ecriture fichier
data/inc_meta_cache.php3
Nov 29 13:50:01 127.0.0.1 (pid 1720) vider le cache

J'ai tué le inc_meta_cache.php3...

et c'est toujours pareil !

JMB

Je fais comme d'hab, je charge les fichiers, supprime le inc_connect.php3...

Quelle drôle d'idée ? Pour une mise à jour il n'est pas utile de supprimer
inc_connect.

Je fais le boulot... et me retrouve avec la mire ! Et ça boucle !

Aïe.

Nov 29 13:50:01 127.0.0.1 (pid 1720) echec ecriture fichier
data/inc_meta_cache.php3

Peut-être as-tu des fichiers bizarres dans ecrire/data/ ou des droits
d'écriture mal installés sur ce répertoire ?

-- Fil

Quelle drôle d'idée ? Pour une mise à jour il n'est pas utile de supprimer
inc_connect.

Bah, quand je ne le faisaia pas, je me plantais souvent ! Donc je le fais
par réflexe maintenant ;-)))

Peut-être as-tu des fichiers bizarres dans ecrire/data/ ou des droits
d'écriture mal installés sur ce répertoire ?

Les droits d'écriture, je n'y crois pas trop, du moins en local.
Des fichiers bizarres ?

un Mysql.log de ce matin, des sessions, des logs de spip, un .htaccess, le
inc_meta_cache et le meta_cache.php3 (c'est normal ?), un cron.lock vide et
c'est tout !

JMB

Nov 29 13:50:01 127.0.0.1 (pid 1720) echec ecriture fichier
data/inc_meta_cache.php3

A cet endroit on utilise encore flock, dont on avait vu qu'il posait quand même des pbs chez certains hébergeurs.
Comme il n'y a pas de risque d'accès concurrent à l'installation, je pense qu'on ne perdrait rien ici à revenir
à l'écriture bien sage fopen+fwrite+fclose. Si le pb persiste, ça aura au moins le mérite de savoir qu'il faut chercher ailleurs.

      Emmanuel

Salut Emmanuel;

A cet endroit on utilise encore flock, dont on avait vu qu'il posait
quand même des pbs chez certains hébergeurs.

En l'occurrence, l'hébergeur est Windows (je sais, désolé ;-)) ) avec
EasyPHP.
Mais je n'ai jamais eu ce problème auparavant !

Comme il n'y a pas de risque d'accès concurrent à l'installation, je
pense qu'on ne perdrait rien ici à revenir
à l'écriture bien sage fopen+fwrite+fclose. Si le pb persiste, ça aura
au moins le mérite de savoir qu'il faut chercher ailleurs.

J'attends que tu poses une correction dans le CVS, ou bien je peux faire une
modif par moi-même ?

JMB

un Mysql.log de ce matin, des sessions, des logs de spip, un .htaccess, le
inc_meta_cache et le meta_cache.php3 (c'est normal ?), un cron.lock vide

et

c'est tout !

Bon !

J'ai rechargé une CVS ce matin, pour venir à un état stable. Et j'ai
supprimé tous les fichiers du répertoire ecrire/data de mon installation.

Maintenant, cela marche et il ne me demande pas de changer de version ma
base (ce qui est, somme toute, normal !).

Par contre, je me pose une question que je me suis toujours posée ! Je ne me
sers jamais de l'installateur et je copie les fichiers directement. Mais
qaund il y a de gros changements de la structure de la base, des
répertoires... des fichiers à supprimer... cette façon de faire n'est pas
très "propre" : avez-vous des conseils à ce sujet ?

JMB