Takes time on Allocation in HTTP Download Manager especially on Large Files !

[shahwaliullah]

other download managers does not take time on starting the download, while http downloader takes time on file allocation.

[erickutcher]

It preallocates the file on the disk before it starts writing data. The reason why it takes so long is because Windows overwrites the preallocated file with zeros as a security precaution.

If you want it to start writing immediately, then you'll need to set "Enable quick file allocation" in the Advanced Options window.

[shahwaliullah]

Thanks

[alxkum]

It preallocates the file on the disk before it starts writing data. The reason why it takes so long is because Windows overwrites the preallocated file with zeros as a security precaution.

This isn't great for SSD longevity.

If you want it to start writing immediately, then you'll need to set "Enable quick file allocation" in the Advanced Options window.

Unfortunately, this requires admin rights and this causes stuff like drag & drop no longer to work.

Why not just write the chunks to the file as they come in? I guess there must be an optimization reason but Firefox etc. have no issue starting a download right away and just writing the file on the fly. Maybe there could be some middle-ground option where it just starts immediately but doesn't require admin rights, sort of the traditional way?

[erickutcher]

If a request returns a compressed data stream or if it's a chunked transfer, then the file will download without being pre-allocated. It does that because the file size isn't known.

Any file that's split into parts and has multiple connections downloading each part will need to be pre-allocated because each part is going to save its data at some offset location in the full file. I could make it an option to disable pre-allocation, but you'd lose the performance gains of being able to split a file into parts. It wouldn't be any different than using a browser's download manager.

Pre-allocation can help prevent disk fragmentation, although that's not an issue with SSDs. I'll look into whatever solutions are out there for SSDs.

[alxkum]

Any file that's split into parts and has multiple connections downloading each part will need to be pre-allocated because each part is going to save its data at some offset location in the full file.

I kinda figured this was the reason but my understanding was "Connection > Default download parts" with a value of 1 will be using a single connection/single part, so the pre-allocation step should be unnecessary then, no? It's just funny that large files take me longer to download with HTTPDownloader due to the pre-allocation step than it is to just download the same file using Firefox with a single connection.

Maybe an option could be to pre-allocate on the fly, like only the necessary parts. For example, the software wants to start the download of part 10 of the file but only the first 6 parts of the file have been pre-allocated so far (parts 7-9 are still in queue) - part 10 would now trigger the pre-allocation of parts 7-10.

Or maybe keep the first pre-allocation step of the entire file but start the download of the file parts that have finished allocating.

[erickutcher]

Any sort of allocation would still cause Windows to overwrite the empty space first before something can be written to it.

I've looked into sparse files and they seem like a decent solution. If they don't work as I think they will, then I'll add an option to disable pre-allocation for single connection downloads.

[erickutcher]

Sparse files seem to work. It'll allocate and start writing immediately. It won't work on FAT systems though and will fall back to the slow method.

[erickutcher]

A new version is up that has this implemented. It's in the Advanced options.

[alxkum]

Works perfectly Eric. Thanks a lot!