Support #5118
fermé
Fichiers renommés lors de la migration v5.13.1
0%
Description
Bonjour,
Après plusieurs tentatives, la migration est passée :- 8:30 de compilation
- La base de données est passée de 851Mo à 4,1Go !!! (dump avant = 37Mo, Après = 66Mo)
- 178 438 fichiers traités
- 3 991 erreurs (fichiers référencés non trouvés)
Cependant, je ne vois aucune modification des noms de fichiers sur le serveur. Est-ce normal ?
Il y a quand même eu beaucoup d'erreur de fichiers non trouvés. Pourquoi ?
Lors de l'opération, nous avion près de 650 fichiers contenant les caractères "\", "?", ":".
Pour accélérer le processus, nous avons utiliser des requêtes pour renommer les fichiers.
Y-a-t'il un risque de renommer les fichiers dans la base données par requêtes ?
La liste des caractères interdits contient ?/\:*<>.
Les serveurs de fichiers ET le portail n'interdisant pas un certains nombres de caractères, il y a beaucoup de caractères encores plus spéciaux dans les noms de fichiers du portail.
Voici un extrait des caractères que j'ai pu trouver : "€" "+" "@" "%" "&" "?" "$" "°" "©" "!" "®", ainsi que bon nombre de caractères accentués divers...
Pouvez-vous valider que ça ne pose pas de problème lors de la procédure ?
Que se passe-t'il si des fichiers n'ont pas pu être renommé ?
Comment le voit-on lors de la migration ?
Tous les fichiers, même ceux ayant posés problèmes, sont-ils toujours accessible ?
Editable en ligne ?
Y-a-t'il désormais, une vérification des caractères autorisés avant le dépôts de fichiers sur le portail ?
Merci de vos réponses.
Fichiers
| Image_125.jpg (25 ko) Image_125.jpg | |||
| test€fichier©encore°.odt (8,69 ko) test€fichier©encore°.odt | |||
| Image_128.jpg (99,5 ko) Image_128.jpg | |||
| launch-2.jnlp (1,83 ko) launch-2.jnlp |
Mis à jour par Emmanuel GRANGE il y a plus de 10 ans
- Fichier Image_125.jpg Image_125.jpg ajouté
Je confirme que l'édition en ligne ne marche pas avec les fichiers contenant des "€"
Par exemple, si j’essaie d'éditer le fichier "SECU 034 - Electrisation CCDV€5.xls", il tente d'ouvrir le fichier avec le nom "SECU 034 - Electrisation CCDVâ,¬5.xls"
Mis à jour par David Lesimple il y a plus de 10 ans
- Fichier test€fichier©encore°.odt test€fichier©encore°.odt ajouté
- Statut changé de New à Feedback
Edition en ligne:
Je viens de faire le test avec un fichier comportant certains de ces caractères.
L'édition en ligne fonctionne bien (Libre office et Silverpeas 5.13.1)
Son mode d'édition est déconnecté (deconnectedMode = true) dans attahcment.properties.
Et sur votre plateforme ?
Mis à jour par Emmanuel GRANGE il y a plus de 10 ans
Nous utilisons : deconnectedMode=false
Mis à jour par David Lesimple il y a plus de 10 ans
Emmanuel GRANGE a écrit :
Bonjour,
Après plusieurs tentatives, la migration est passée :
- 8:30 de compilation
- La base de données est passée de 851Mo à 4,1Go !!! (dump avant = 37Mo, Après = 66Mo)
vacuumdb
- 178 438 fichiers traités
- 3 991 erreurs (fichiers référencés non trouvés)
Cependant, je ne vois aucune modification des noms de fichiers sur le serveur. Est-ce normal ?
Les fichiers transmis par l'utilisateur (ce qui exclut les fichiers système) sont bien déplacés et leurs noms sont bien modifiés.
Ils sont modifiés grâce aux informations stockées en BdD (colonne physicalName).
Il y a quand même eu beaucoup d'erreur de fichiers non trouvés. Pourquoi ?
Avec le temps et l'utilisation de Silverpeas, des fichiers peuvent être référencés encore en base de données alors qu'ils ont été en fait supprimés de la plate-forme et donc du disque (ceci est dû en partie à d'anciennes versions de Silverpeas). C'est pourquoi, le processus de migration, qui parcours la base de données afin de savoir quoi migrer, informe par un message d'erreur qu'en fait, tel ou tel autre fichier n'a pas été trouvé alors qu'il est référencé encore en base de données.
Lors de l'opération, nous avion près de 650 fichiers contenant les caractères "\", "?", ":".
Pour accélérer le processus, nous avons utiliser des requêtes pour renommer les fichiers.
Y-a-t'il un risque de renommer les fichiers dans la base données par requêtes ?
Il n'y a aucun risque puisque la liaison (pour la migration) est réalisée par le nom physique sur disque (avant migration). C'est la colonne attachmentPhysicalName.
Aucun risque donc à modifier la colonne attachmentLogicalName avant la migration.
La liste des caractères interdits contient ?/\:*<>.
Les serveurs de fichiers ET le portail n'interdisant pas un certains nombres de caractères, il y a beaucoup de caractères encores plus spéciaux dans les noms de fichiers du portail.
Voici un extrait des caractères que j'ai pu trouver : "€" "+" "@" "%" "&" "?" "$" "°" "©" "!" "®", ainsi que bon nombre de caractères accentués divers...
Pouvez-vous valider que ça ne pose pas de problème lors de la procédure ?
Que se passe-t'il si des fichiers n'ont pas pu être renommé ?
Si le nom des fichiers pouvant poser problème n'a pas été renommé avant la migration, il y a un risque que celle-ci ne les trouve pas et par conséquent ne les migre pas. Auquel cas, ils seront alors considérés comme perdus par la plate-forme mais seront toujours présents sur le disque.
Comment le voit-on lors de la migration ?
Le fichier dbbuilder.log affiche les erreurs de fichiers non trouvés. A partir de celles-ci, vous pouvez vérifier si cela est du à un problème lié à leur nom. Si il y a bcp d'erreurs, il sera nécessaire d'écrire un script pour automatiser la vérification.
Tous les fichiers, même ceux ayant posés problèmes, sont-ils toujours accessible ?
Non, les fichiers indiqués en erreur sont considérés comme non existant. C'est le cas dans plus de 99% des cas.
Editable en ligne ?
non
Y-a-t'il désormais, une vérification des caractères autorisés avant le dépôts de fichiers sur le portail ?
A certains endroits oui, ou alors les caractères interdits sont remplacés à la volée.
mais il y a peut-etre des endroits où ce n'est pas fait.
Merci de vos réponses.
Mis à jour par David Lesimple il y a plus de 10 ans
Concernant l'édition en ligne, cela fonctionne bien avec Libre Office sur VOTRE plateforme de test.
(avec le fichier test€fichier©encore°.odt)
Mis à jour par Emmanuel GRANGE il y a plus de 10 ans
- Fichier Image_128.jpg Image_128.jpg ajouté
Je pense qu'il s'agit plus d'un bug de l'édition en ligne "connectée" :
Lorsque j'essaie d'éditer le fichier "SECU 034 - Electrisation CCDV€5.xls" nouvellement déposé sur le portail, il tente toujours d'ouvrir le fichier "SECU 034 - Electrisation CCDVâ,¬5.xls", et m'affiche l'erreur suivante :
J'ai le problème avec Windows XP/Office 2000, Windows 7/Office 2000
Je vais tester les autres configurations
Mis à jour par Emmanuel GRANGE il y a plus de 10 ans
- Fichier launch-2.jnlp launch-2.jnlp ajouté
L'édition en ligne de fichier LibreOffice ne pose effectivement pas de problème, en mode connecté ou non.
Les fichiers sont bien renommés sur le serveur mais lors d'une édition en ligne sous Microsoft Office, l'applet d'édition ne retranscrit pas correctement le nom du fichier.
Dans le launch.jnlp, le nom du fichier converti en code hexa ne correspond pas au nom exact du fichier :
SECU%2520034%2520-%2520Electrisation%2520CCDV%25E2%2582%25AC5.xls == SECU 034 - Electrisation CCDVâ,¬5.xls
Mis à jour par David Lesimple il y a plus de 10 ans
- Sujet changé de Fichiers renommés lors de la migration v5.131 à Fichiers renommés lors de la migration v5.13.1
- Catégorie changé de Fichiers joints à Edition en ligne
- Statut changé de Feedback à Qualified
- Navigateur changé de Firefox 10 à Tous
Dans ce cas précis, il semble que l'url soit encodée 2 fois, une première fois l'espace est encodé %20 et le %20 est encodé une deuxième fois
pour donner %2520 car %25 correspond à l'encodage du %.
Mis à jour par Miguel Moquillon il y a plus de 10 ans
- Statut changé de Qualified à Resolved
Pour ce qui est des problèmes des caractères non-ASCII dans les noms de fichiers avec l'édition en ligne, la version 5.13.2 a apporté une correction de bogue sur ce sujet pour les versions de MS-Office >= 2007. Par contre, nous ne pouvons garantir cette correction avec Ms-Office 2000, plus supporté par Microsoft depuis juillet 2009,.