100% CPU usage and lock-ups while resuming large downloads

[anonymous]

Upon resuming an FTP download of a large file, Filezilla takes up 100% of CPU usage on Windows 98 SE, and mouse pointer movement gets extremely sluggish. After the connection is established, all returns to normal. If the download fails, Filezilla will retry the connection, and upon resuming it again the problem happens again but worse: the system seems to lock up completely for about 60 seconds (sometimes more, sometimes less). Most of the times, the connection is established and the system becomes responsive again after that lock-up period, but sometimes the lock-ups require a hardware reset.

If more than one large file are being downloaded, the lock-up caused by one transfer can make the others fail, so that they in turn lock the system up and make the first resumed download fail too.

This only happens when the resume position (the parameter for the RSET command) is large enough. Resuming the download of a large file on a position near zero doesn't cause any lock-up.

I guess (without looking at Filezilla's source) that there's some blocking call being made while Filezilla waits for the remote server to seek() to the RSET position.

In case that this be a server-dependent bug in Filezilla (I don't think it is), here's an example: I've experienced this problem while downloading the Mandrake distribution from many of the USA mirrors (for example, ​http://www1.mandrakelinux.com/ftpredir.php?url=ftp://mirror.cs.wisc.edu/pub/mirrors/linux/Mandrakelinux/official/iso/10.0/i586&tpc=mirrors-iso-Mandrakelinux-10.0-Official-inst-i586.txt ). This is a 700 Mb file. And for the record, Filezilla was run on a 400 Mhz AMD K6-3 processor.

[Tim Kosse]

I think this may have to do with your system. Somehow,
seeking within files seems to take a huge amount of
resources on your system.
One reason for this could be virus scanners or firewalls