Jump to content

error 'insufficient disk space' while there's plenty of space


alex9

Recommended Posts

Posted

.DMP files are with either your .EXE or settings.dat file. (%PROGRAMFILES%\uTorrent or %APPDATA%\uTorrent )

Right... what settings are you using compact_allocation, sparse files, disk cache settings under Advanced screen in Preferences?

  • Replies 76
  • Created
  • Last Reply
Posted

bt.compact_allocation=false

diskio.sparse_files=false

In disk caching everything is checked except:

Override automatic cache size, increase automatic size when cache thrashing, and disable windows caching if disk reads.

I don't think I changed any of the settings from default.

And as an update Ive been using the fragile version all day and of course now its working perfectly.

Posted

I've installed that version linked and now received two crashes. The first I clicked on 'submit this dump to the developers'. Now I have it up again, does anyone want me to do anything else with it? Or do I keep 'sending the dump to developers'?

Posted

Sounds like it's easier for them right now to directly link the crashdmps to the specific problem they're for... if you could browse to the settings.dat or utorrent.exe directory, locate the .DMP files, compress them, and upload them to http://mediafire.com, and edit/post with the URL to that file, it would help them :D

Posted

I continue to have the problem, now even when downloading just one torrent, with a fairly slow download (<50kB/s.) I also have PeerGuardian running.

I tried going back to 1.7.7 but I still get the errors. Is there some kind of special uninstall I have to go through to go back to 1.7? I REALLY don't want to use Azureus again (what a resource hog.) I've only got a dual-core processor, I don't know what I'd need to make Azureus feel fast.

Posted

It appears that after updating to 1.8.1 beta build 11903 everything seems to be working just fine! :)

dls running smoothly for 15 minutes now.

will let u know how it does on the long run.

Posted

OK, I used the process monitor to see what was happening when it dies. Here's the part of the logfile from right around when the download stopped:

http://www.mediafire.com/?gj5lxmg2jms

(This is when I'm running 1.7.7 and still getting the error, after I upgraded to 1.8, and went back to 1.7.7.)

Hope that helps.

@alex9,

I tried upgrading to that beta, and continued to have the problem.

Posted

I had this exact same problem and unchecking disable windows caching of disk reads fixed it (enable disk writes, enable disk reads, and disable windows disk writes still checked). No pre-allocation of files, compact allocation set to false, sparse files set to true.

Posted

I just followed them settings and it didn't do a bit of difference unfortunately :(

Message came up within about 3 minutes!

Fed up now, going to look for a different program for the mean time!

***************************

Well that didn't work either.

I downloaded and tried BitLord, BitTorrent and BitComet and all three experienced the same problem!

This is strange!!! It never happened up until about 2 weeks ago.

The only program which it doesn't seem to happen to is 'Vuze', and I don't like it - it's just too much and 'in your face' so to speak.

At least it rules out a specific problem with uTorrent - unless it's damaged some registry files or something?

Posted

"I don't know about damage to the hard drive being as likely as extremely badly crosslinked files and lost allocation units."

But if that is the case wouldn't that indicate a more severe problem with the program than we thought since the files weren't crosslinked and the allocation units were snug in their beds before the latest version of UTorrent started freaking out and left the drive in such a mess even other programs wont work right?

Posted

One power outage or one program crashing (possibly during windows shutdown/reboot) can cause lost allocation units.

Just run a disk check...to rule it out as a possibility!

Posted

But that doesn't explain why multiple users experience the same problem, all since the upgrade to 1.8. I've gone back to 1.7.3, which I never had any problem with (never had a problem with any version before 1.8) and just had a program crash - I'm a HEAVY user, and have never had that happen so soon after starting the program. Maybe after a couple months it might have problems, but never after a few minutes.

AVG Antivirus just had a big upgrade recently, so I also wondered if that had anything to do with it, but I disabled it and no change.

I also installed the new "Vuze" (Azureus) and was shocked to see the crap it had become - trying to be like the bittorrent version of iTunes or something. I guess everyone has a right to make a buck... Also tried BitComet, but it's just so lacking in ease of use and is missing so much that I now expect from a client. Also so s..l..o..w.. what's up with that? It didn't crash, but still... Another thing that makes both Azureus and BitComet unacceptable is that for some reason, when I'm using them on my server, my other machines on my network can't get satisfactory network performance. They seem to choke everything up. uTorrent does that so much less, I can't believe it. I'm back to trying to solve my uTorrent problems so my life can return to normal.

Posted

Don't use anything below 1.7.7 IF you choose to not run 1.8 (which is patched against at least 3 more public security vulnerabilities than your odd choice for a "stable" build)...

Have you checked your settings for pre-allocate/compact/sparse files ... like mentioned above? Or what about the Disk Cache options...

And as to why people experience the same problem, without HJT or PE logs for comparison of all running processes I'd venture a guess there's something running which uTorrent hasn't been tested with yet. Firstly if you could run that test build, and save the .DMP files compress a few together and upload them to http://mediafire.com and link it here that would be useful. Additionally if you can/will do another ProcMon dump, I think they prefer the save type to be .PML instead of CSV :)

After looking through your logfile, I see something called "memturbo" and superantispyware... Can you try running uT overnight or... for a few hours WITHOUT it installed?

You're also running emule simultaneously :/

The relevant parts I guess are

"102159","1:08:09.9451140 PM","uTorrent.exe","2716","WriteFile","D:\Program Files\Azureus\Downloads\[FILE]Disc 1.mpg","FAST IO DISALLOWED","Offset: 2,424,307,712, Length: 1,048,576"

"102160","1:08:09.9452679 PM","uTorrent.exe","2716","WriteFile","D:\Program Files\Azureus\Downloads\[FILE]Disc 1.mpg","DISK FULL","Offset: 2,424,307,712, Length: 1,048,576"

Posted

The 1.7.3 crash may have been a fluke, something maybe to do with picking up a torrent I'd switched to BitComet and then back to uTorrent. I tried 1.7.7, thought I got the same errors a couple times, so I went back to the earlier build, picked at random. I just knew I'd never had troubles with any of those old builds, but couldn't say for certain if I ever did upgrade to 1.7.7 before going to 1.8, so I wondered if the problem wasn't new with 1.8.

I know I started 1.7.7 after installing it, but when I restarted it later, I now realize the link I used was to my installed 1.8, which I thought I had installed 1.7.7 on top of. Turns out I had both installed on my machine at the same time. So 1.7.7 didn't have the same error after all. Now I'll move to that and see if all is well so I can get caught up on my DLs, then I'll try crashing the fragile build and getting some data. My current DL is so large that the re-check after a crash takes a long time, so I prefer doing testing with something smaller.

Posted

well, the main problem of this topic is fixed by updating to 1.8.1 beta build 11903 as far as I know.

no more faulty disk space error, its been running ok for many hours now. no crashes ever here btw

thanks for all the help

Posted

"After looking through your logfile, I see something called "memturbo" and superantispyware... Can you try running uT overnight or... for a few hours WITHOUT it installed?

You're also running emule simultaneously"

I can verify that these arent the problem as I don't have them installed.

Perhaps its running UTorrent in conjunction with another program that does a lot of read/writes to the same (physical) drive?

Posted

I am having the same problem, the file is already cached on disk, fitting 100% of its final size, but utorrent keeps using more space until fill all disk, maybe with junk, because the file is already 100% cached, then the "no disk space" appear.

Posted

zhd

uTorrent 1.8? Check the Advanced > diskio.sparse_files option. It is enabled by default in 1.8 which means file is only virtually "fitting 100% of its final size" untill the actual content is downloaded.

Archived

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

×
×
  • Create New...