Discussion :

[Jimmy_]

J'ai peut-être pas suivit, mais n'empèche qu'essayer de deviner si le fichier est bien arrivé à postériori, c'est du brin, comme on dit. C'est la fonction d'envoi du fichier qui doit s'assurer que le fichier est bien envoyé et pas une fonction situé après.
Et puis parser une log vous êtes sérieux ?

Il n'y a qu'une seule méthode fiable à 100% c'est d'envoyer un SIZE par ftp. Tout le reste peu laisser passer des erreurs ou n'est pas propre.

[jabbounet]

Pour compléter un peu, le protocole FTP est décrit dans la RFC 959 http://www.ietf.org/rfc/rfc0959.txt.

La façon dont ftp gère ses connexion ainsi que les commandes et les codes de retour sont normalisés. Avoir quelques détails sur le fonctionnement interne de FTP pourra peu être t'aider à trouver une solution.

Ceci dit j'ai l'impression qu'il manque quelque chose dans ton process, personnellement je ne vois pas moyen fiable de savoir si le transfert est terminé si ce n'est pas ton application qui le gère ou qu'un système externe te notifie la fin du transfert.

Si j'ai bien compris ton process:
1. l'utilisateur se connecte a ta machine en utilisant ftp.
2 l'utilisateur envoi un fichier sur ta machine (en utilisant ftp).
3. l'application scan le répertoire de destination. (il devrait recevoir une notification par quelque chose ou quelqu'un)
4. quand un nouveau fichier est présent tu le récupère.

J'ai déjà eu a faire une application similaire (un petit webservice en c#) il y'a quelques années, il devait charger des fichiers configurations sous forme de fichiers tar.gz pour un banc de test.

Dans les grandes lignes le process était le suivant:
1. l'utilisateur se connecte à l'application (interface soap)
2. l’utilisateur indique le serveur ftp et le fichier à charger.
3. l'application se connecte au serveur et télécharge le fichier.

Cette solution à l'avantage de laisser à l’application le soin de gérer le transfert avec le serveur ftp et donc de le contrôler totalement.

[tchize_]

J'ai peut-être pas suivit, mais n'empèche qu'essayer de deviner si le fichier est bien arrivé à postériori, c'est du brin, comme on dit.

Bienvenue dans les environnement Legacy et les système en production qu'on ne peut pas toucher. C'est moche, mais c'est la vraie vie, celle ou on travaille, pas celle de l'école. Il a été clair à ce sujet. Il n'a aucun controle sur les système qui envoient le fichier, il doit travailler dessus à posteriori.

[wax78]

Et puis parser une log vous êtes sérieux ?

Non non je disais ca pour vous faire parler (je blague .

Bien sure et pourquoi pas ?

Des gens upload des fichiers, et j'ai envie de savoir qui a mis quoi et quand pour chaque mois envoyez un mail automatiquement par exemple. Je fais comment si je n'ai qu'un fichier log a disposition ou eventelement acces au fichier et l'arbo du ftp ?

Si j'accede au fichier pour comparer si il y'a eu ajout/suppresion etc, je risque de toute maniere de tomber sur d'eventuel fichier pas fini de transferer. A moins que le serveur ftp efface les fichiers non finis de transferer ...

Sinon le log, peut s'il existe, et est assez complet, marquer clairement et pour chaque commande ce qui a ete fait par qui/quand et le status de la commande et c'est fiable a 100%. J'aimerai devenir serieux et comprendre

Sinon pour le SIZE, ok, j'ai dut louper le passage ou il connait la taille des fichiers.

[yotta]

Bonsoir,

J'ai beaucoup réfléchit à votre problème de savoir si un fichier est complet ou pas dans ce contexte. Si j'ai bien tout compris, votre vrai problème, c'est de vouloir copier un fichier que le serveur FTP est en train d'écrire sur le disque. J'ai cru aussi comprendre que votre programme tournait sur la même machine que le serveur FTP en question. Donc, je penses qu'il peut être pertinent de intéresser à une valeur particulière que l'objet File nous permet de récupérer le plus simplement du monde : lastModified()
Cette méthode renvoie l'instant t en millisecondes de la dernière modification du fichier sur le disque. D'un autre côté, on récupère l'instant t qui nous concerne avec :

Code :

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

1
2
 
Calendar.getInstance().getTimeInMillis()

On se donne une petite marge de disons 10 secondes, soit 10.000 millisecondes.
Il suffit alors de considérer que tout fichiers dont lastModified() n'est pas supèrieur d'au moins 10.000 millisecondes de getTimeInMillis() représente un fichier en cours d'écriture. Il suffit alors de passer au fichier suivant, etc, etc...

[dugenoux]

A ce que je vois, mon problème n'est pas si facile que ça à résoudre...

j'ai testé différentes façons et pour l'instant la meilleure (mais lourde) est la suivante :

je récupère les fichiers transférés si ils n'ont pas d'activités depluis plus de 15 secondes

Code :

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

1
2
 
(new Date().getTime() - new Date(fichier.lastModified()).getTime()) > 15000

normalement ça devrait être bon, mais comme je ne suis jamais sur de rien, je copie ce fichier dans un répertoire temporaire et ensuite je le charge dans une BufferedImage

Code :

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

1
2
 
imageTemp = ImageIO.read(new File("c:/Temp/temp.jpg"));

et ensuite je teste chacun des pixels de la dernière ligne de cette BufferedImage

Code :

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

1
2
3
4
5
 
for (int a = 1; a < imageTemp.getWidth(); a++) {
   if (imageTemp.getRGB(a, imageTemp.getHeight() - 1) == Color.GRAY.getRGB())
        b++;
}

si il y a au moins la moitié de pixels gris je garde le fichier pour traitement ultérieur, la moitié car il peut y avoir du gris dans l'image...

Code :

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

1
2
3
 
if (b < imageTemp.getWidth()/2)
  UtilFiles.copyFile(fichier, new File(cheminTemp + fichier.getName()));

dans mon traitement je mémorise dans une table le nom du fichier réceptionné et, si au passage suivant de mon thread, le fichier récupéré existe je le supprime du dossier de réception ftp.

c'est long mais ça marche... pour l'instant.
heureusement que c'est une image en jpg, parce que si c'était un Word ou autre je ne sais pas comment j'aurai pu tester les pixels gris

bien sur si un petit malin envoi autre chose que du jpg, j'ai mis un contrôle du type MIME et de l'extension.

merci de votre aide à tous

[yotta]

Dans tous les cas de figure, le principe d'une connexion FTP étant de pouvoir interrompre un transfert de fichier en vue de le reprendre là où l'on s'était arrêté montre par lui-même que le résultat en terme de fichier local sur le serveur est fatalement un fichier 'complet' et exploitable. Il est donc tout simplement impossible, localement, de déterminer si un fichier est complet, ou incomplet. Le seul élément qui connaisse cette information (un fichier est-il complet ou pas) n'est autre que le serveur FTP lui-même.Il ne reste donc que les logs du serveur pour trouver des repères qui permettent de détecter de tels fichiers.
Par contre, mais je ne l'ai pas vérifié, il pourrait être intéressant de comparer ce que le client FTP obtient comme taille de fichier, et la taille réelle du fichier local concerné. Il n'est pas impossible que dans le cas de fichiers incomplet, elle ne correspondent pas. Pour réaliser cette comparaison, il vous faudra vous connecter localement en tant que client FTP (un user et un password de client qui accède au dossier de dépôt Jpeg seront suffisant), et interroger en tant que client FTP le serveur pour lui demander la taille du fichier à tester...

Autre alternative possible. En toute logique, pour permettre à un serveur d'interrompre un transfert tout en donnant la possibilité de le reprendre sans recommencer à zero signifie obligatoirement que le serveur connaisse la taille finale du fichier, et sa taille locale réelle. En étudiant le protocole FTP j'ai remarqué qu'un client, s'il veut reprendre un transfert demande un marqueur au serveur. Je suppose que ce marqueur permet de reprendre le transfert au bon endroit. Donc, le serveur associe logiquement un marqueur a chaque fichier incomplet. Dans ce cas, si cette hypothèse est vraie, il suffit de se connecter en tant que client FTP au serveur pour lui demander si le fichier à tester comporte un marqueur. Dans l'affirmative cela signifierait que le fichier est incomplet, et dans l'autre cas qu'il est complet ?