General concerns about changed file sizes

[mathiascode]

Due to various online discussions about damaged/corrupted files shared on the Soulseek network over the years, I've been looking into ways to ensure Nicotine+ contributes to this issue as little as possible.

The official clients seem to permanently stick to whatever file size was given to them when they first added a download to their list. There's no way for the uploader to know what file size the downloader wants, which means any changes in the files on the uploader's end after this (e.g. audio tag changes) can either:

• Result in a corrupted file that contains both data from the old and updated file, if the download had started and paused midway through previously
• Result in a truncated file, if the changed file is larger than the original one

A solution for this (which the official clients don't do) is to update the file size of the download with the new value from the TransferRequest peer message, and discard any previous incomplete download if the file size has changed. Of course, SoulseekQt sends 0 as the size in this message for uploads over 2 GB, so you'd have to keep using the cached file size in this case. unfortunately.

Is this something you're doing in Soulseek.NET/slskd? If not, I would suggest using the new size in the TransferRequest message.
Example in Nicotine+:
https://github.com/nicotine-plus/nicotine-plus/blob/5721d97df1971feff4d716b73b686b4acc1ef6ff/pynicotine/transfers.py#L763-L773
https://github.com/nicotine-plus/nicotine-plus/blob/5721d97df1971feff4d716b73b686b4acc1ef6ff/pynicotine/transfers.py#L1049-L1052

[jpdillingham]

I'm finally getting around to reviewing the code, and I think this is a great idea.

For downloads I use the size provided in the search result/browse request. If no size is supplied, the size from the transfer request is used. I think what I'll do is continue to do this, but compare the two sizes and throw if they don't match (and the remote size is > 0). The caller will be on the hook to re-request the file with the updated size (and decide what to do with any partial download).

I guess on second thought I'll need to make the behavior configurable. In almost all cases the remedy will be to discard the partial download and use the remote size, and if I throw the download will need to be re-enqueued.

[jpdillingham]

Captured in #710