Intermittent "Missing Files" errors because qBittorrent does not properly account for libtorrent duplicate filename resolution.

[WIPlemInProgress]

edit: i resubmitted this in the issue tracker somebody should probably delete it, or the issue, idk

this is my understanding of how libtorrent filename conflicts are supposed to be resolved:

• you build an add_torrent_params out of .fastresume data with read_resume_data()
• you build a torrent_info out of the original .torrent data with the torrent_info constructor
• crucially, the torrent_info constructor updates the file list with resolve_duplicate_filenames()
• you stick the torrent_info in the add_torrent_params
• you pass the add_torrent_params to the libtorrent session
• when torrent.init() gets called it updates the already deduped file list with the renamed_files from the fastresume data if there are any
• when torret.write_resume_data() gets called it notices files() diverges from orig_files() (because we passed the session a torrent_info with a deduplicated file list) and packs the returned add_torrent_params with the renamed_files
• when we write .fastresume data it properly reflects that we have renamed_files and diverged from the original .torrent; this way even if libtorrent deduping logic changes in the future it won't break torrents that were already downloaded with previous versions

the way qbittorrent uses libtorrent is breaking this:

• the user adds a .torrent to the UI
• crucially, we pack an AddTorrentParams with a file list pulled from TorrentInfo which wraps torrent_info but pulls from orig_files() instead of files() thus ignoring libtorrent deduplication
• we let the user select/rename files etc and update the AddTorrentParams and at the end pass it to the qbitorrent session
• qbittorrent session packs the entire AddTorrentParams file list into add_torrent_params renamed_files
• this gets passed to the libtorrent session
• (or something similar to that, i didnt really follow the UI logic, but we are definitely populating the UI with a non-deduped filelist from TorrentInfo and passing that list to libtorrent session by packing it all into renamed_files somewhere)
• libtorrent torrent.init() updates the file list with the original non-deduped file list being passed through renamed_files
• on a platform like linux everything downloads, on a platform like windows maybe some stuff with conflicting filenames doesn't download
• when libtorrent torrent.write_resume_data() gets called it sees that files() and orig_files() match (unless the user renamed something) so doesn't return any renamed_files
• we don't write any renamed_files in the .fastresume

on next session:

• ResumeDataStorage builds a LoadTorrentParams with an add_torrent_params inside it and a torrent_info inside it
• crucially, this torrent_info once again includes a list of deduped filenames
• we pass the LoadTorrentParams to the qbittorrent session which passes the libtorrent data to the libtorrent session
• the disk_io thread is told to check files
• verify_resume_data() fails because get_filesize() fails because we look for the deduped files on disk but we didn't use deduped names when downloading the torrent in the first place
• the UI shows the torrent with a "Missing Files" error and demands a force recheck to proceed with the torrent
• at the same time, the UI has been populated with a file list from the qbitorrent Torrent which pulls orig_files from TorrentInfo and renamed_files from what was passed, neither of which contain the deduped filenames, so the UI does not reflect the deduped file list the libtorrent backend is currently using
• since we're in an error state nothing gets called to rewrite .fastresume with the deduped filenames
• restarting qbitorrent changes nothing, we are stuck in a failure loop

still in that same session:

• if the user proceed with the force recheck it will verify all the files except the ones libtorrent is using the "wrong" filenames for
• at the moment the recheck completes some event handler calls manageActualFilePaths() which notices unexpected actualFilePath(s) and calls doRename() to "fix" them which successfully replaces the deduped filenames in the libtorrent session with the non-deduped names the UI has been using
• if the user proceeds to download the same files will be redownloaded in the same place (or fail to download on a platform like windows)
• since we're once again using the original filenames instead of the deduped ones we don't write any renamed_files in .fastresume
• on next restart we get the same "Missing Files" error
• restarting qbittorrent changes nothing, we are stuck in a failure loop

another funny thing:

• what if when presented with "Missing Files" the user does not immediately force recheck?
• at this exact moment the libtorrent backend contains a filelist with the deduped filenames
• so if they do something to force a resume data update (like, say, simply right-clicking on the torrent in the UI and renaming it), * torrent.write_resume_data() will notice the filelist doesn't match orig_files() and return resumedata with the correctly deduped renamed_files
• if they exit immediately after that the renamed_files will be saved in .fastresume, thus breaking the loop (but still requiring the set of deduped files to be redownloaded to a new location on next session)
• if instead of exiting they proceed with the force recheck in the same session it will once again result in manageActualFilePaths() nuking the deduped names putting us back in the loop

another another funny thing:

• what if the user adds a torrent with conflicted filenames but exits without starting it or before it downloads any of the conflicted files?
• we immediately hit the manageActualFilePaths() loop on restart

how to fix this?

• in src/base/bittorrent/torrentinfo.cpp:
• replace "return torrentInfo.orig_files();" in getFileStorage() with "return torrentInfo.files();"
• ???
• idk there is probably some deep architectural and future ABI and v2 merkle trees reasons not to do this