C’est un problème qui existe peut être depuis toujours sans être lié directement à SPIP mais je voudrais savoir s’il y a moyen de le corriger dans une version prochaine du système…
Comme vous le savez, la plupart des herbergeurs utilisent des serveurs sous UNIX qui font bien la différence entre un fichier toto.jpg et Toto.jpg, on peut bien avoir les 2 fichiers présents dans IMG/jpg/
Quand avec SPIP on essaie d’ajouter un fichier dont un homonyme existe déjà (toto.jpg) le nouveau fichier est appelé par exemple toto-2.jpg (génial). Néanmoins si Toto.jpg existe déjà, pas de renomage, on installe à côté toto.jpg (pas de souci sous unix).
Maintenant, imaginez: un honnête (mais un peu idiot comme moi par exemple) administrateur fait depuis des années des sauvegardes de ses sites hébergés sous linux vers un système, windows par exemple, qui ne fait pas de différence entre toto et Toto et TOTO et totO… Un site dont les utilisateurs font preuve de très peu d’originalité sur le choix des noms de fichier. Il sauvegarde donc sans s’en appercevoir pendant des années non pas 4 mais un seul fichier toto ! Et le jour ou le serveur pête, où qu’il passe sur un serveur sous windows (là il est vraiment trop con), il se retrouve avec une grouille monstre dans ses images. Certaines manquantes, d’autres déformées (dans la base la taille ne corresponds pas). Lui qui était si fier d’annoncer à son chef que pas de souci, on a des tas de sauvegardes !
Voyez mon souci ? Ce serait donc bien par exemple d’étendre le système du renomage: si un fichier toto.jpg existe déjà et qu’un utilisateur ajoute Toto.jpg, celui ci soit renommé par exemple en Toto-2.jpg ou toto-2.jpg… Suis je seul idiot à réaliser mes sauvegardes sous windows ? Remarquez qu’administrateur idiot + utilisateur sans imagination + serveur qui pète, c’est pas bol.
Salut Nicolas,
pour le futur, je rajoute un
$file[‹ name ›] = strtolower(translitteration($file[‹ name ›]));
dans la recuperation du nom de fichier, ce qui evitera les collisions dont tu parles en passant tous les noms de fichier en minuscule.
pour les sites déjà existants (comme le tien), on peut faire une moulinette si besoin, mais en perdant du coup d’éventuels liens directs vers les fichiers.
Salut Nicolas,
pour le futur, je rajoute un
$file['name'] = strtolower(translitteration($file['name']));
dans la recuperation du nom de fichier, ce qui evitera les collisions dont
tu parles en passant tous les noms de fichier en minuscule.
pour les sites déjà existants (comme le tien), on peut faire une moulinette
si besoin, mais en perdant du coup d'éventuels liens directs vers les
fichiers.
[...]
Bonsoir,
je suis totalement opposé à ce genre de chose si c'est imposé.
En effet, si on change la case des caractères, ce sont les noms en
chinois qui seront cassés, de plus, certains comme moi, utilisent
des caractères avec une case différente pour certains repérage, donc
ça me poserait un problème plus tard.
Concernant le chinois, c'est dommage que les caractères chinois d'un
nom de fichier soient simplement effacés.
Je propose que ce soit une option : laisser les caractères tel quels
en important un fichier, ou les translitérer quand c'est possible,
et éventuellement les passer en bas de case.
Ce genre de problème, c'est comme la sécurité. Est ce que c'est à
Spip de s'occuper des tares de windows? d'une mauvaise configuration
du serveur? Il y a déjà les problèmes avec les serveurs Windows IIS
qui savent pas gérer les .htaccess proprement (et toute une autre
série de limitations).
Concernant les calculs sur certaines images, si on veut éviter
qu'elles soient touchées, il suffit de ne pas demander à Spip d'y
toucher, et d'utiliser les attributs ( filtre insert_attribut{})
pour ajouter les dimensions dans la balise IMG. Non? (comme ça, tes
.gif seront intacts.)