Lorsque j'écrase un fichier distant avec une copie locale, FileZilla transfère et écrase le fichier avec succès, mais je remarque que la taille de la nouvelle copie distante est inférieure de quelques Ko à celle de la copie locale actuelle. Pourquoi cela se produit-il ?
Réponses
Trop de publicités?Meder fait référence, je pense, à des extrémités de ligne différentes entre Linux et Windows. Alors que les *NIX n'utilisent qu'un seul caractère (ASCII 10) pour un saut de ligne, Windows en utilise 2 (ASCII 13 + ACII 10).
Les programmes FTP disposent généralement d'un mode "transfert de texte" ou "transfert ASCII" (par rapport au mode "transfert binaire"), qui convertit automatiquement ces caractères, si nécessaire.
Ainsi, si votre fichier comporte 1000 lignes, il est plus grand de 1kB sur Win que sur les systèmes *NIX.
Dans Filezilla, vous pouvez déterminer le mode de transfert via Transfer
-> Transfer Mode
dans la barre de menu.
Il pourrait y avoir une autre raison à laquelle je pense, bien qu'elle soit hautement improbable. Si vous calculez les Kilo-Bytes, vous pouvez définir 1kB = 1024 Bytes (unité SI) ou vous pouvez définir 1KiB = 1000 Bytes (unité IEC, notez le "Ki" au lieu de "k"). Cela donnera également des tailles différentes, mais dans tous les cas, je sais que les tailles sont calculées de la même manière des deux côtés d'une connexion.
Peut-être cela est-il lié à la différence entre "Taille" et "Taille sur le disque" :
Size est la taille réelle du fichier en octets.
La taille sur le disque est la quantité réelle d'espace occupé sur le disque.
Ainsi, si la taille de votre secteur est de 512 octets et que votre fichier fait en réalité 513 octets, la taille sur le disque sera de 1024 octets car il occupe deux secteurs.
Comme les différents systèmes d'exploitation ou disques peuvent utiliser des tailles de secteur différentes, si la taille indiquée est la "taille sur le disque", les tailles seront différentes.
Si le serveur a un système d'exploitation différent, c'est la raison (par exemple, serveur = Linux, local = Windows). Il se peut aussi que certains octets aient été supprimés par votre faute ou par celle de votre éditeur de texte (les espaces blancs sont traités différemment selon les éditeurs). Ce serait une bonne supposition sans voir réellement la différence entre les deux.
J'ai remarqué cette divergence lors de la copie de fichiers d'un système DOMAIN/OS de type unix vers Windows, mais comme j'utilise toujours le transfert binaire (même avec texte fichiers) J'ai dû chercher l'explication ailleurs.
J'ai remarqué que sur mon système, la taille originale du fichier est exprimée comme un nombre entier de tampons : des multiples de 32kB, et que lorsque le fichier est transféré, seuls les octets réels du fichier sont comptés.
Mais j'utilise un système étrange et ancien, et je pense que l'explication de meder est plus susceptible d'être correcte.