Projet

Général

Profil

Actions

Support #5118

fermé

Fichiers renommés lors de la migration v5.13.1

Ajouté par Emmanuel GRANGE il y a environ 11 ans. Mis à jour il y a presque 11 ans.

Statut:
Closed
Priorité:
High
Assigné à:
-
Catégorie:
Edition en ligne
Version cible:
-
Début:
20/11/2013
Echéance:
% réalisé:

0%

Temps estimé:
Navigateur:
Tous
Votre version de Silverpeas:
5.13
Système d'exploitation:
Linux
Livraison en TEST:
Livraison en PROD:

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 Emmanuel GRANGE, 20/11/2013 14:31
test€fichier©encore°.odt (8,69 ko) test€fichier©encore°.odt David Lesimple, 21/11/2013 15:43
Image_128.jpg (99,5 ko) Image_128.jpg Emmanuel GRANGE, 25/11/2013 09:02
launch-2.jnlp (1,83 ko) launch-2.jnlp Emmanuel GRANGE, 25/11/2013 11:09

Demandes liées 2 (0 ouverte2 fermées)

Lié à Silverpeas Core - Bug #5203: Impossible d'éditer en ligne avec Office2000Closed13/01/2014

Actions
Copié vers GED - Bug #5139: Pb edition en ligne suite migration 5.13.1ClosedMiguel Moquillon20/11/2013

Actions

Mis à jour par Emmanuel GRANGE il y a environ 11 ans

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 environ 11 ans

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 environ 11 ans

Nous utilisons : deconnectedMode=false

Mis à jour par David Lesimple il y a environ 11 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 environ 11 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 environ 11 ans

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 environ 11 ans

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 presque 11 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 Emmanuel GRANGE il y a presque 11 ans

Y-a-t'il une solution ?

Mis à jour par Miguel Moquillon il y a presque 11 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,.

Mis à jour par David Lesimple il y a presque 11 ans

  • Statut changé de Resolved à Closed
Actions

Formats disponibles : Atom PDF