What does the software on encountering an empty (0 bytes) resume in .config/transmission/resume/ during start-up? Decides to download anew, even if the data file (or files) were completely downloaded. An amazingly stupid behaviour, given that the software has such command as “Verify Local Data” in the Torrent menu. The program should verify data of a torrent damaged this way and, if successful, assume that the data are present in their entirety. How probable is a partially downloaded file having the hash matching the hash of the original? Practically improbable (unless somebody intentionally created and shared a file having the hash with very unusual properties). On the other hand, truncated files (especially, volatile files) are a common sight after system crashes, and can also happen after writing attempts during no-room events on a filesystem.
Moreover, suppose that the data file has its last modification timestamp many weeks in the past. On lost resume/⋯, would it be reasonable to silently restart downloading (even if hash verification failed or is not possible)? No, because such condition indicates that this item was not downloaded for weeks. Such torrent should be paused, pending intervention by the operator.
Ī̲ observed the gotcha/foolishness on transmission-gtk 2.94 last time and doubt that anyone cared to discuss (or fix) it already.
Feature requests not specific to either the Mac OS X or GTK+ versions of Transmission
1 post • Page 1 of 1