That's rather strange.

The downloads.dat file must have been read successfully. - If LimeWire, however did quit unexpectedly, or if there was an error while the downloads.dat file was written, LimeWire currently could loose all infomation on which parts of the files were already downloaded. The next version, although I know it won't help you, will fix this by saving the downloads.dat every thirty seconds while running.

Former (pre-swarming) versions did not have this problem, since they didn't have to save any data on which blocks of a file were written. Maybe it was a mistake, that the LimeWire developers released the swarming feature before it was really ready, but other p2p-clients like kazaa and xolox clearly put them under pressure to act, which resulted in many releases in short intervals creating bugs, fixing bugs and creating new ones.

That's the way it is, the more thoroughly you test something, the longer it takes you to implement the same amount of features.

"The bug was fixed in LimeWire 2.3."

thats where the bug was introduced! previous versions worked fine, but now i can't resume. if the download stops, and starts up again (in the same session, it starts at zero and i see the file disappear from the download folder!

"I know it's working on Linux and Windows now."

isn't this the mac part of the forum?

"The file, that is used to save the downloads, downloads.dat is saved when you close LimeWire and when you add / kill downloads."

mabye so, but it still doesn't resume. i got 98% of a 153mb file and now i have to start over again and can't seem to get past 10% now before it stops.

Another odd bug about this is when the file isn't even done yet, maybe about half way the file size is the size of the full file when downloading from multiple hosts at the same time. i watched an episode of family guy all the way through before it was even done downloading. lucky i watched it too since it disappeared when the connection was dropped and i had to start over.