Opened 11 years ago
Closed 10 years ago
#8278 closed Bug report (outdated)
File size transferred for large file is way over the original size
|Reported by:||Erik Johansson||Owned by:|
|Keywords:||transferred file size too big||Cc:||erik.johansson@…|
|Component version:||Operating system type:||Windows|
|Operating system version:||Windows 7 6b bit|
FTP Server: Windows server 2003 R2 x86
Client operating system: Windows 7 x64
File Zilla: 3.5.3, Build date: 2012-01-08
Server and client filesystem: NTFS
Connection: VPN tunnel using native windows client to ISA 2006 server running on Windows 2003 R2 x86 with shared key L2TPipsec connection.
FileZilla set to transfer binary file.
File type: VMware vmdk file.
Server side size using Windows Explorer: 2,687,200 KB
Server side size using Windows 7 native FTP client: 2,751,692,288
Server side using filezilla: 2,751,692,288
Size of transferred file using filezilla interface: 4,636,080,127
Size of transferred file using Windows cmd: same
The file size is reported correctly by FileZilla. Starting the transfer by dragging the file to the client window correctly starts the transfer. The time of transfer seems to be correctly reported using the file size and the transfer speeed (as displayed). When the progress window reaches the original file size, it reports zero time left. However, the transfter continues and in the case creates a much bigger file.
To me this seems like some kind of bug.
Change History (3)
comment:1 by , 11 years ago
|Status:||new → moreinfo|
comment:2 by , 11 years ago
As you are using IIS, this might be a duplicate of #4672 if you are resuming an aborted download.
comment:3 by , 10 years ago
|Status:||moreinfo → closed|
No reply for more than 28 days.
Please re-open this issue once you have more details to share.
This looks like a duplicate of #7834.
Can you please provide logs? Did the download resume or does the problem happen without resuming?