Resuming a download with deleted .part files results in zero-padded sparse file

[TomArrow]

Here's precisely what I did:

Started downloading file, finished under 10%. Ended jDownloader2, removed the hard drive the download was to (dockingstation), put in another hard drive with a different drive letter. Opened jDownloader 2 without starting downloads. Changed download location of partially downloaded file to new drive, same folder path but new drive letter.

After resuming the download, instead of recognizing the missing .part file and starting from zero, jDownloader 2 continued from the percentage that it last reached and "successfully" finished the download.

The resulting file didn't work because the headers were missing. It was a sparse file, meaning the reported "Size on Disk" was smaller than the reported "Size" in the properties window (Windows 7 Ultimate 64-bit). The discrepance in size was equivalent to how much was initially downloaded before switching the drives. Opening the file in HxD (hex editor) showed that the first few percent of the file (the ones that don't really exist on the physical drive) were completely filled with zeros.

Upon noticing this, I didn't bother to finish another download that had the same problem. I inspected the .part file of said download and it too was a sparse file led with zeros.

Hoster was uptobox.com

I suspect that jDownloader2 isn't performing a file_exists check (dunno what it's called in Java), but rather just opens a file for writing at the position it last remembers, which results in it auto-creating the non-existent file and starting the write operation at where it thinks it last stopped, resulting in a sparse file that has no content in the beginning.

Proposed solution, always check whether a .part file exists before starting a write operation.