Discussion :

[snay13]

Bonjour à tous

Je vous expose mon problème

J'ai un ecouteur sur un dossier qui vérifie si de nouveaux fichiers sont apparus toutes les secondes. Lorsqu'un fichier arrive je lance un traitement assez long de conversion d'image

Mon problème est lorsque je reçoit des fichiers lourds, le fichier apparait avant la fin de son écriture et donc mon traitement se lance et plante une erreur.

Comment puis je vérifier que mon fichier est bien complet avant de lancer mon traitement ?

J'ai essayé de comparer le poids du fichier toutes les secondes , le hashCode mais rien n'y fait

Une Idée??

[tchize_]

il n'y a pas moyen de la savoir, la plupart des application n'informent même pas l'OS qu'elles ont "fini" de traiter un fichier. Ta seule solution et d'ouvrir le fichier suivant le format défini, et si le fichier ne respecte pas le format, supposer qu'il n'est pas encore prêt.

Tu peux aussi vérifier si le fichier est verrouillé, mais il y a très peu d'applications qui écrivent en faisant ça. Sous windows -> en écriture le verrouillage est automatique, donc impossible de lire pendant que le fichier est ouvert en écriture. Sous linux il existera un fichier .lck portant le même nom que le fichier.

Tu peu aussi voir les tutoriels et cours de formation à la programmation Java : http://java.developpez.com/cours/

[snay13]

Merci de ta réponse

Je m'en doutais mais jeme disais qu'il existait peut être une solution miracle

Mais bon il faut que j'arrive tout de même à contourner le pb. Les fichiers que je recoit proviennent d'un scanner.

Tu me dis qu'il faut que je joue avec les erreurs que j'ai ou que j'ai pas

Je vais tenter de récupérer alors le nombre de page du fichier. Normalement si le fichier n' a pas fini d'être écrit il devrait me mettre une erreur et la je shunte le traitement.

Je reviens après les test

[snay13]

Après quelques test, j'arrive à le faire fonctionner mais ca me semble pas très propre

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
try
                    {
                            PdfReader reader = new PdfReader(liste[i]);
                            reader.close();
                    } catch (Exception e)   {     break;    }
                    createImage = new ThreadImage(liste[i], timerEcouteDossierImage);
                    createImage.execute();

N'y a t'il vraiment aucun autre moyen que de jouer sur les erreurs?

[tchize_]

déjà ne catche pas Exception, mais l'exception précise que tu veux traiter.

Si l'api que tu utilise (itext) ne fournis pas de méthode explicite pour tester la validité d'un fichier, tu n'a pas d'autre choix que de tenter d'ouvrir et voir ce qui se passe. Maintenant ce n'est pas parce que le pdf n'est pas valide que le générateur n'a pas fini, il a peut être planté ou merdé

Sur quel OS dois tourner l'application? Sous linux t'as éventuellement l'option de faire un "lsof | grep noDuFichier.pdf" pour voir si une autre application, possédée par le même utilisateur que ton application java, a ouvert ce fichier.

Aussi, n'as-tu pas le controle sur le logiciel qui fait le scanning, pour savoir quand l'opération est terminée?

[snay13]

L'application est voué à tourner sous Seven

Les scan que je recoit proviennent de multifonction où je n'ai aucun controle si ce n'est le type de fichier le taux de compression et autre chose qui me sont inutile dans ce cas

L'ideal serait effectivement de pouvoir tester si le fichier est utilisé puisque lorsque j'ai une erreur pour un scan assez lourd, Le message d'erreur me précise quil est en cours d'utilisation.

Apparemment une telle fonction n'existe pas sous iText mais je continue à chercher si je ne suis passer à coté d'une méthode

PS : Je me sers uniquement de iText pour calculer le nombre de page du fichier dans ce cas pour savoir si le fichier est complet. Sinon le traitement du fichier en image est réalisé par ghostScript

[tchize_]

tu peux nous mettre l'erreur?

[snay13]

Voila l'erreur en enlevant la détection d'erreur par le nombre de page vec iText

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
Ecouteur des Dossiers Images
Debut de Capture : c:\scanTekProd\Exercices_De_Guitare_Pour_Les_Nuls.pdf
Ecouteur des Fichiers PDF
[INFO] Ghostscript  - GPL Ghostscript 8.71 (2010-02-10)
[INFO] Ghostscript  - Copyright (C) 2010 Artifex Software, Inc.  All rights reserved.
[INFO] Ghostscript  - This software comes with NO WARRANTY: see the file PUBLIC for details.
[INFO] Ghostscript  - Error: /undefinedfilename in (c:\\scanTekProd\\Exercices_De_Guitare_Pour_Les_Nuls.pdf)
[INFO] Ghostscript  - Operand stack:
[INFO] Ghostscript  - 
[INFO] Ghostscript  - Execution stack:
[INFO] Ghostscript  -    %interp_exit   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   --nostringval--   false   1   %stopped_push
[INFO] Ghostscript  - Dictionary stack:
[INFO] Ghostscript  -    --dict:1157/1684(ro)(G)--   --dict:0/20(G)--   --dict:70/200(L)--
[INFO] Ghostscript  - Current allocation mode is local
[INFO] Ghostscript  - Last OS error: Permission denied
[ERROR] Ghostscript  - GPL Ghostscript 8.71: Unrecoverable error, exit code 1
ERROR: Cannot initialize Ghostscript interpreter. Error code is -100
Fin de Capture : c:\scanTekProd\Exercices_De_Guitare_Pour_Les_Nuls.pdf

J'ai fait ce test en copiant manuellement un fichier PDF de 380Mo (rarement atteint en scan) dans le répertoire source

[tchize_]

comme test tu peux aussi éventuellement tenter un new FileInputStream(fichier), il me semble que sous windows ca déclenchera une erreur.

[snay13]

J'ai testé cette solution que tu m'as donné

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
try
                    {
                        FileInputStream test = new FileInputStream(new File(liste[i]));
                    } catch (IOException e)   {     break;    }

Elle me convient mieux que celle que j'ai fait avec iText car j'avais un lèger ralentissement de quelques secondes suite à le détection d'erreur. Là apparemment je n'ai aucun ralentissement avec ta solution

Je pense que je vais garder ce code vu qu'il n'ya pas d'autres solutions

Merci Tchize pour ton aide