|
Post by ibay770 on Oct 28, 2024 22:42:44 GMT -8
As explained in this thread: superuser.com/questions/213954/why-is-windows-explorer-a-lot-slower-than-filezilla-when-doing-ftp-transfersInternet Explorer and Windows Explorer have a static buffer size of 4096 bytes that can't be changed, in comparison to that Filezilla has a buffer size of 256 KB. The buffer size of Filezilla is thus 64 times biffer than that of Windows Explorer, and that explains why it capable of doing much faster transfers. When this buffer gets filled, which goes very fast for 4096 bytes, it starts delaying loading additional data. So rather than loading a full 256 KB and sending that it only loads up to 4 KB. This takes down the upload speed as some delay is introduced. You can change a thousand network and I/O settings but it will likely not have much effect. FTP programs have way better support as well as features such as simultaneous transfers and resuming a failed transfer, which makes Windows Explorer the wrong tool to be used in this case. So, Windows Explorer isn't really made to do FTP transfers. On the other hand, one could assume a widely used file manager to be capable of doing FTP transfers, but they haven't came around to implement better behavior... Not really legal, one could reverse engineer and try to patch the value! But why if one has Filezilla? Because explorer is more integrated, and because we can! The idea being, maybe someone can track down and change the value to something bigger.
|
|
|
Post by TechSalt on Oct 29, 2024 2:10:26 GMT -8
I think the best way would be to make a shell extension that replaces it with a whole new client but functions exactly the same as the original so we could not only increase the buffer size, but we can also for example, implement FTPS support.
|
|
|
Post by ibay770 on Oct 29, 2024 9:19:37 GMT -8
Agreed. Problem is. I don't know how to do that. We could do the same with archive extraction too, the Microsoft implementation is decades old.
|
|