Description
Shareaza doesn't seem able to anticipate that the currently available space on the receiving volume won't allow downloading a given file or a given chunk (based on this inability to use the “sparse” feature), and sometimes mindlessly continues to receive new chunks until free space goes down to nearly 0, then (and only then) pauses every single active download, even those which have 0 sources and are therefore not liable to cause any trouble. Sometimes when a file is being downloaded when the available space gets too low, some chunks end up corrupted, and then it mindlessly rejects the source which transmitted those chunks identified as corrupted (for no other reason than the insufficient space) as if they were the culprit! And so one has to make unnecessary actions to resume that download through an inordinately convoluted process (usually it involves using advanced features like “assume the file is 100% complete and reverify”, then resuming, sometimes re-adding the specific source if there is only one and it's not re-added automatically... that kind of aggravation which could and should be prevented by design...). I may have to create a specific bug report for that second part, but I figured that it was sufficiently linked with the main subject of this one to add it here.