Project

General

Profile

Actions

Support #5118

closed

Fichiers renommés lors de la migration v5.13.1

Added by Emmanuel GRANGE about 8 years ago. Updated almost 8 years ago.

Status:
Closed
Priority:
High
Assignee:
-
Category:
Edition en ligne
Target version:
-
Start date:
11/20/2013
Due date:
% Done:

0%

Estimated time:
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.


Files

Image_125.jpg (25 KB) Image_125.jpg Emmanuel GRANGE, 11/20/2013 02:31 PM
test€fichier©encore°.odt (8.69 KB) test€fichier©encore°.odt David Lesimple, 11/21/2013 03:43 PM
Image_128.jpg (99.5 KB) Image_128.jpg Emmanuel GRANGE, 11/25/2013 09:02 AM
launch-2.jnlp (1.83 KB) launch-2.jnlp Emmanuel GRANGE, 11/25/2013 11:09 AM

Related issues

Related to Silverpeas Core - Bug #5203: Impossible d'éditer en ligne avec Office2000Closed01/13/2014

Actions
Copied to GED - Bug #5139: Pb edition en ligne suite migration 5.13.1ClosedMiguel Moquillon11/20/2013

Actions
Actions #1

Updated by Emmanuel GRANGE about 8 years ago

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"

Actions #2

Updated by David Lesimple about 8 years ago

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 ?

Actions #3

Updated by Emmanuel GRANGE about 8 years ago

Nous utilisons : deconnectedMode=false

Actions #4

Updated by David Lesimple about 8 years ago

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.

Actions #5

Updated by David Lesimple about 8 years ago

Concernant l'édition en ligne, cela fonctionne bien avec Libre Office sur VOTRE plateforme de test.
(avec le fichier test€fichier©encore°.odt)

Actions #6

Updated by Emmanuel GRANGE about 8 years ago

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

Actions #7

Updated by Emmanuel GRANGE about 8 years ago

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

Actions #8

Updated by David Lesimple about 8 years ago

  • Subject changed from Fichiers renommés lors de la migration v5.131 to Fichiers renommés lors de la migration v5.13.1
  • Category changed from Fichiers joints to Edition en ligne
  • Status changed from Feedback to Qualified
  • Navigateur changed from Firefox 10 to 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 %.

Actions #9

Updated by Emmanuel GRANGE about 8 years ago

Y-a-t'il une solution ?

Actions #10

Updated by Miguel Moquillon about 8 years ago

  • Status changed from Qualified to 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,.

Actions #11

Updated by David Lesimple almost 8 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF