Jump to content

Out of Disk Space Dyn Allocation should NOT Stop the Download


bs9999

Recommended Posts

One of my pet peeves about this program is when i am downloading a large file and because of how it is set up i have uTorrent allocate space as it needs it. If, however, i run out of disk space the app completely stops the download process. Recall that as it downloads pieces it may come at different parts of the file and thus the app will have to allocate all required space in between...knowing this there is no reason for the app to stop the download....just download the missing parts found in the existing allocation......This is why i keep BitComet still because it realizes this and never stops my downloads...it just alerts me and continues on...The peeve of uTorrent doing this is that when i wake up in the morning i find nothing has downloaded....

Link to comment
Share on other sites

  • 3 months later...

Thanks for the reply Ultima...Sorry for the late reply....And thanks for the reply...I guess what i am trying to suggest is something that is "simple" to implement into uTorrent (i am a programmer and i know exactly what is involved) and would continue to show the cleverness of uTorrent. What makes a good program great is being able to anticipate things before the user sees them.

Think about it, wouldnt it be a piss off to see a download uncessarily stop when it had allocated enough space already to download at least a portion of the file? As a user i shouldnt have to "babysit" every little thing. Sure, when there is absolutely no space then it has no choice to stop, but unnecessarily stopping when it allocates 4.10 GB of a 4.11 GB file just because its missing 10 megs of diskspace is not logical when the program can full well download 4.10 GB...that 99.9% versus 0%.

I already realised all i have to do is keep monitoring my disk space but ask yourself "why SHOULDNT uTorrent be able to be Smart enough to know about this already" ... BitComet and other clients already handle this issue properly and is the primary reason why i keep BitComet as my primary client simply because the author is willing to keep ahead of the user.

If u'd like please send me the source and i'd be happy to implement this fix in a few hours and you can verify the code...happy to help because uTorrent is pretty good and should continue to improve

Link to comment
Share on other sites

I would agree for a multi-file torrent for it to continue on the files it COULD fully allocate, but not for files that do not have enough disk space. There's quite a few pitfalls that occur when other clients don't recognize you cannot download certain pieces due to them being un-allocatable. Some might even treat your ip as a hostile, to say nothing of the weird internal errors µTorrent would probably be getting with data that's bound for out-of-space portions of a torrent.

Link to comment
Share on other sites

Hi Switeck..thanks for the useful reply! I am sure you know more than me in regards to how uTorrent manages its files but as i sit back in my chair and think about it i just dont see how a feasible pitfall could arise to warrant other clients to assume my ip was hostile simply because "my side" cant download certain pieces due to allocatable issues...the worst case senerio for either side is i just can't download those pieces...its my side's lost, not others.

My first thoughts as a remote user when i see this scenerio is 1) he is out of disk space or 2) he is priortizing which pieces he wants. If he is prioritizing then maybe the idea that he isn't sharing fairly can be suggested but still all the remote side would need to do is re-balance how it shares in return, and as such, the one who isn't downloading certain pieces would just get fewer download opportunities.

Regardless, i just find that other clients have implemented such a feature successfully and I find that uTorrent, despite its elegance, has forgone such a nifty, yet hardly spoken about, feature.

Link to comment
Share on other sites

µTorrent writes files in one of three ways:

- Compact allocation: the file is extended for each piece, and if the disk is full there is no way to proceed

- Sparse allocation: the end-of-file size is set and allocation occurs as it's written to; there is no spare 'unused' space in the file -- if the disk is full you can't continue

- Neither of the above: the file is fully allocated at start and is unaffected by available disk space; this is the default method

Maybe I'm misunderstanding, but I just don't see where you think you're going to find allocated-but-unwritten-to file space in the event of a write failure due to a full volume.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...