Discussion :

[Herode]

Bonjour à tous,

Je cherche à uploader une archive .zip sur un serveur distant. L'archive locale est valide (testé par moi). Pour la liaison FTP j'utilise la classe FTPClient de org.apache.commons.net.ftp.FTPClient. L'upload se fait comme suit :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
	    	    FileInputStream fis = new FileInputStream(new File(localFile));
	    try {
		if (!ftp.storeFile(remoteFile, fis)) {
		    throw new Exception("FTP host refused to store file " + localFile + " at " + remoteFile);
		}
 
		return true;
	    } catch (IOException ioe) {
		logger.severe(ioe.getMessage());
		return false;
	    } finally {
		fis.close();
	    }

Problème : le fichier qui se trouve sur le serveur est inexploitable. Si je fais un unzip dessus, j'ai comme réponse :

1128 extra bytes at beginning or within zipfile. [...] zipfile corrupt

Avez-vous une idée pour corriger ce problème ?

[bluefingers]

Je ferais bien un md5 sur le fichier transmis pour m'assurer qu'il est réellement différent du fichier original.

En Général quand un fichier est modifié par ftp c'est qu'il s'agit d'un fichier binaire transmis avec l'option ASCII. Il faudrait donc contrôler ce point dans la configuration de ton objet ftp.

la méthode setFileType(FTP.BINARY_FILE_TYPE) me semble appropriée.

[Herode]

Haaaa oui, ça marche bien mieux comme ça en effet.

Merci !

Une question subsidiaire pour ma culture personnelle si quelqu'un a un peu de temps à perdre : pourquoi FTP modifie t'il un fichier ASCII ?

[thelvin]

Conventions de fin de ligne différentes. Genre CRLF d'un côté et juste LF de l'autre.

À une époque, qui a beaucoup influencé FTP, ce genre de différences passaient pour une "différence de manière d'enregistrer des fichiers d'un système à un autre."
Aujourd'hui ça passe plutôt pour deux formats textes différents, sans qu'il soit question de système.