Discussion :

[FFF]

Bonjour,

Suite à une copie de fichiers réalisée en java (ou via un logiciel), j'ai remarqué qu'il est fréquent que les tailles sur le disque des fichiers sources et cibles (affichées par windows) sont très légèrement différentes. Cela vient-il de windows ? de la façon de copier le fichier ? du disque lui même ? de la façon de lire la taille des fichiers selon windows ?

merci.

[dinver]

Tu es sure de poser la question dans le bon forum :

[FFF]

ben elle est valable aussi pour le forum windows. en fait j'ai fait une application réseau pour copier un fichier et ce fichier. Après plusieurs copies, le fichier n'a plus forcément la même taille qu'à l'origine... je vois pas d'où ça vient ?

[dinver]

ben elle est valable aussi pour le forum windows. en fait j'ai fait une application réseau pour copier un fichier et ce fichier. Après plusieurs copies, le fichier n'a plus forcément la même taille qu'à l'origine... je vois pas d'où ça vient ?

assez bizarre

Une question toute bête, lorsque la taille a changé le fichier reste accessible càd CRC ok en d'autre terme tu peux lire ton fichier et ses données ne sont pas corrompus ?

[ghorgor]

Une question bete, ca pourrait pas venir soit d'un writer pas bien fermé a la fin, soit de fin de lignes pas tout a fait ecrites comme dans les fichier source ?

A priori, la taille doit etre la meme, un octet d'un poste a l'autre reste un octet et fait toujours 8 bits... Donc, pas normal...

[dinver]

Une question bete, ca pourrait pas venir soit d'un writer pas bien fermé a la fin, soit de fin de lignes pas tout a fait ecrites comme dans les fichier source ?

A priori, la taille doit etre la meme, un octet d'un poste a l'autre reste un octet et fait toujours 8 bits... Donc, pas normal...

C'est pour ça que je me demande si le fichier dont la taille n'est pas la même ne doit pas être le même. Soit qu'il est corrompu soit qu'il y a eu une modification quelconque lors de l'envoie du fichier par réseau

[ghorgor]

Tiens, d'ailleurs, tu l'envoies comment ton fichier par le reseau ?

c'est en texte, en binaire, les deux ?

Tires tu bien la chasse a la fin de l'envoi ? (Flush...)

[FFF]

en fait mon programme est assez compliqué. Mais grosso modo j'envoie la fichier sous forme de byte (bien qu'il y ait eu découpage par morceau puis compression....)
Les fichiers copiés ne sont pas corrompus car ils sont tout à fait lisibles...
J'ai essayé avec de la musique, du texte et les fichiers ne sont pas corrompus.
Non je n'ai pas mis de flush() (le programme d'envoi est une classe ftp téléchargée depuis ce site). Mais j'utilise à chaque envoi une nouvelle classe ftp, donc à priori le buffer est vide à chaque fois... . Dois-je en rajouter ?

Mais cette erreure n'est pas sytématique, il arrive souvent que le fichier copié ait la même taille que celui d'origine...

Merci pour vos réponses

[adiGuba]

Salut,


Tu aurais du préciser de suite que ce n'est pas une copie en local mais par FTP !!!

Lors de l'envoi de fichiers par FTP en mode ASCII, les fin de ligne sont transformé afin de gérer les différences entres les systèmes (\n sous *n*x, \r sous Mac, et \n\r ou \r\n sous Windows).

Il est donc possible que les fichiers changent de tailles...
Si généralement cela n'a pas trop d'impact pour les fichiers textes, c'est plus délicat pour les fichiers binaires qui peuvent être altéré...

Dans ce cas il faut faire le tranfert en mode binaire afin que le fichier soit envoyé tel quel !

a++

[FFF]

Tu aurais du préciser de suite que ce n'est pas une copie en local mais par FTP !!!

désolé ! !

Lors de l'envoi de fichiers par FTP en mode ASCII, les fin de ligne sont transformé afin de gérer les différences entres les systèmes (\n sous *n*x, \r sous Mac, et \n\r ou \r\n sous Windows).

Il est donc possible que les fichiers changent de tailles...
Si généralement cela n'a pas trop d'impact pour les fichiers textes, c'est plus délicat pour les fichiers binaires qui peuvent être altéré...

Dans ce cas il faut faire le tranfert en mode binaire afin que le fichier soit envoyé tel quel !

effectivement je crois que tu tapes dans le mille puisque ma classe ftp ne semble pas activer le mode binaire par défaut lors de l'upload de fichier...
sachant que j'upload sur un serveur linux ! De plus la différence de taille n'est de quelques octets supplémentaires sous windows... mais ça n'explique pas pourquoi certaines fois j'ai une copie exacte (le bol ?, le serveur ftp qui travaille ?)...

je vais activer le mode binaire manuellement donc.
Merci pour vos réponses.

PS :
ce qui m'avais poussé à accusé windows au début c'est que j'avais effectué une copie d'un fichier de 1 Go sur un disque externe (usb) et j'obtenais une différence de taille de quelques octets là aussi (je pensais que cela pouvais venir du format des disques dur qui étaient différents (histoires de tailles d'allocation 2048, 4096..)mais j'y connais rien dans ce domaine donc ce ne sont que des hypothèses.
bizzard... peut être cela vient de l'usb qui fait des écritures incertaines...

[zekey]

Et le type d'encodage utilisé ?

[FFF]

Et le type d'encodage utilisé ?

je ne vois pas de quoi tu parles ? précise.

[MangeurVasqué]

Ca peut venir des file systems et de la taille de leurs secteurs.

Si je ne dis pas de bêtises, un fichier occuppe toujours un nombre entier de secteurs sur un disque. Par conséquent, un fichier possède :
* une taille réelle
* une taille occuppée sur le disque qui est un multiple de la taille des secteurs.

La taille des secteurs n'étant pas à priori la même sur 2 systèmes de fichiers différents, tu obtiens des tailles apparentes différentes.

[zekey]

Ben selon le type d'encodage des caractères ascii/utf8/16. Mais vraisemblablement ce serait plutot un probleme de taille de bloc.
Pour etre sure tu pourrais executer l'outil md5sum sur les deux systeme et vérifé que le checksum est bien identique, si c'est le cas alors il s'agit plus vraisembleblement d'une différence de blocs de données.

[Pitivier]

Bonjour,

j'ai le même problème...

J'ai une appli qui fait des sauvegardes de fichiers d'un disque vers un autre. Les fichiers sauvegardés sont des fichiers binaires (images, mp3, vidéos...) et lors de la copie, j'ai remarqué effectivement que la taille du fichier destination n'est pas toujours la même que celle du fichier d'origine. Même lorsque la taille est modifiée, le fichier destination reste lisible mais dans le cas de fichiers mp3, les tags ID3 semblent être perdues. A priori, le problème se manifeste toujours sur les mêmes fichiers.

Je constate ce problème même lors de mes tests en local sur mon PC. Dans cet environnement, les fichiers sont copié d'un répertoire vers un autre. Les deux répertoires sont sur le même disque et la même partition.

ma méthode de copie de fichiers est toute simple :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
public static void copyFile(File srcFile, File dstFile) throws IOException, FileNotFoundException {
   byte[] buffer = new byte[5000];
   FileOutputStream fos = new FileOutputStream(dstFile);
   FileinputStream fis = new FileinputStream(srcFile);
   while(fis.read(buffer) != -1) {
      fos.write(buffer);
   }
   fis.close();
   fos.close();
}

si vous avez des pistes, je suis preneur.

merci

[adiGuba]

Salut,


La méthode write(byte[]) écrit la totalité du buffer dans le fichier. Or lorsque tu arrives à la fin du fichier, il y a de fortes chances que ton buffer ne soit pas rempli (du coup le reste du buffer comporte les éléments lu précédemment)...

Il faut donc que tu conserves le nombre de caractères lu par read() pour n'écrire que ceux-là :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
public static void copyFile(File srcFile, File dstFile) throws IOException, FileNotFoundException {
	byte[] buffer = new byte[5000];
	int readCount = 0;
	FileOutputStream fos = new FileOutputStream(dstFile);
	FileinputStream fis = new FileinputStream(srcFile);
 
	while( (readCount = fis.read(buffer)) != -1) {
		fos.write(buffer, 0, readCount);
	}
 
	fis.close();
	fos.close();
}

a++

[Pitivier]

je suis une buse.... ca m'apprendra à mieux lire les javadoc.

Merci pour la réponse rapide.

[jowo]

ne serait-il pas préférable d'écrire ta méthode de copie ainsi:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
public static void copyFile(File srcFile, File dstFile) throws IOException, FileNotFoundException {
   static final int SIZE = 5 * 1024;
   byte[] buffer = new byte[SIZE];
   long read = 0;
   FileOutputStream fos = new FileOutputStream(dstFile);
   FileinputStream fis = new FileinputStream(srcFile);
   while((read = fis.read(buffer, 0, SIZE)) != -1) {
      fos.write(buffer, 0, read);
   }
   fis.close();
   fos.close();
}

[adiGuba]

ne serait-il pas préférable d'écrire ta méthode de copie ainsi:

Pas forcément puisque le code suivant :

Code :

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

read(buffer);

est équivalent à

Code :

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

read(buffer, 0, buffer.length);

Il n'y a donc pas de risque de buffer-overflow (si c'est bien à quoi tu pensais)...

a++

[jowo]

ne serait-il pas préférable d'écrire ta méthode de copie ainsi:

Pas forcément puisque le code suivant :

Code :

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

read(buffer);

est équivalent à

Code :

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

read(buffer, 0, buffer.length);

Il n'y a donc pas de risque de buffer-overflow (si c'est bien à quoi tu pensais)...

a++

Non, je pensais plutôt au problème que tu as soulevé avec le write.

Avec read(buffer, 0, buffer.length), on est un "petit schouia" plus rapide vu que nous avons un appel à une méthode en moins.
[/code]