Force Recheck 'often' corrupts files that constitute part of a set.

[oldspammer]

I double checked this:

1. Have 4 of say 20 files 100% and the other 16 marked as do not download . Save the containing folder of these 100% completed files to another folder for reference purposes on another disk--let's refer to this as the REF set (for reference purposes). Also make a copy of the original torrent file that these files came from--lets call this T-REF for torrent-reference. Two of my such files were 350 Mbytes and the other two were under 100 kbytes.

2. Let's refer to the original torrent and folder and files as ORIG-for original, and T-ORIG for torrent original.

3. In your running copy of uTorrent delete the ORIG and the T-ORIG via delete torrent and data context menu item.

4. While uTorrent is still running, re-create the ORIG files and folder, and the T-ORIG via the backup copy of REF, then double click open the T-ORIG file. Before clicking on OK for all of the 20 files, just select for downloading the 4 from the set that are the ones that you know are completed already from REF and T-REF, then click on OK.

5. The T-ORIG should now be downloading again, but now we can right click the T-ORIG entry in uTorrent and select "Force Recheck."

For me and the torrent that I tried this with, a couple of the files are renamed to be .!ut (as is expected with incomplete files) and are declared as only 92% completed when they actually were 100% in REF for T-REF. And now uTorrent wants to download again about 4 Mbytes of data needlessly--so delete both the torrent and the data so as not to waste bandwidth and so that we can proceed to the next step in this procedure.

6. Repeat the above steps 4 & 5 except set the copied ORIG files in the copied / new ORIG folder to be "read-only" prior to opening T-ORIG for torrent re-start. This time both uTorrent and the "Force Recheck" operation will not be easily able to taint the files or rename them to .!ut. Now the recheck for the selected 4 of 20 files shall succeed and show that the files are 100% completed (and not the badly re-computed 92% amount), and the new T-ORIG torrent will immediately go into seeding or queued seeding since, afterall, the files were 100% completed anyway.

This sequence was repeatable for my particular torrent. On other occasions, the problem I'm describing may not happen? What I'm saying is that it may not be a universally true situation.

My set of files=this season. Fiction usually from the future. It was recently "not renewed." "1 to nine" in an easily sortable numeric designation was part of its torrent filename. Recent two biggest files in the set and associated smaller files.

[Ultima]

How is this a bug? There is no such thing as files in BitTorrent, so if you're missing ANY part of a piece while µTorrent is rechecking (and pieces can span multiple files -- hence the reason I say there is no such thing as files) then µTorrent will chuck the pieces. Nothing wrong with that, as µTorrent can't tell whether an incomplete piece is corrupt or not.

[DreadWingKnight]

User misinterpertation of protocol implementation is not a bug.

[oldspammer]

So, I'm a newbee to uTorrent protocols.

Please shed light on how so much information got trashed, and destine for re-downloading (of exactly the same identical data)?

From some FAQ: "In the next box, the piece size can be chosen. It is recommended to leave this at auto."

What would the auto-method choose for an X Gbyte data set?

Given a ".torrent" file, how do you find out the piece size from it?

In version 1.6 right-clicking the uTorrent list entry for a torrent and selecting properties does not display piece size--maybe it should?

If a piece is modest size, then my contiguous set of data should have had only two fractional pieces missing--one piece chunk at the front and another one at the end of the torrent data? So would this be the missing approx. 4 Mbytes that gets scrapped by uTorrent when the 100% completed files are Write-enabled?

When done in read-only file mode, why does uTorrent then say that the data was OK and 100% completed if pieces were bordered / fractional / not checkable for any / all data?

Maybe it would be a nice feature request to process such potential / actually completed files as read-only?

[Ultima]

Auto selects based on trying to get smaller piece sizes, yet attempting to make a .torrent file with a reasonable amount of pieces in it (not an extremely high amount -- 65536 pieces is the limit to the number of pieces µTorrent will handle).

You can find the piece size from the General tab after clicking on the torrent. No point putting that statistic on the properties dialog.

Sure, missing 4MB sounds about right, but I can't really make an accurate guess without knowing the piece size, or how many (or what) pieces are actually missing.

Fractional pieces can NOT be checked, as there is no hash data to compare it against, so they are rightly chucked by µTorrent -- it doesn't know if the piece is just incomplete, or if it's incomplete but poisoned data, and it can't know. And such a feature request wouldn't make sense because µTorrent can't tell if a file is considered complete.