I don't have a link - but the credit goes to Kenneth Corbin and Philippe Verdy.

FYI,

I just merged in a change to provide better backup support for the downloads.dat file. It goes through the following steps:

Before writing downloads.dat, rename the existing one to downloads.bak. If writing the file fails at any time, delete the current downloads.dat and copy the old downloads.bak to downloads.dat.

When starting up, if reading the downloads.dat file fails for any reason, it will try to read downloads.bak. If that succeeds, it will copy downloads.bak to downloads.dat.

Thanks for the info and update.

I have lost my fileurns.cache file several times last week (due to Apple JVM bugs), how painful this is depends upon how many files you share. I have just submitted a patch to implement the same backup strategy for that file as well.

A crash wiped out a 219 MB dld at 76%. After reading sberlin's post, I used this method: started dld again and, at 40%, copied downloads.dat and named it downloads.bak (I left it in incomplete folder). Went on dlding, until a scheduled shutdown occurred. When I resumed dlding, to my horror, it started at 0%. So I went to incomplete folder, removed downloads.dat and renamed downloads.bak (the one with the dld at 40%) as downloads.dat. Started dld of the file, but it still started at 0% not the expected 40%. What did I do wrong? Did I have to do sthg with the partially dlded file?
I am using LW basic 3.2 on M%acOS 9.2.2

Manually copying it might not work -- LimeWire writes the file every 30 seconds, so chances are rather high that you copied it 'during' a write, so the file wasn't actually finished.

Some people have also reported problems where resuming a file does not display the correct percentage immediately. However, one a second result is found and the file starts to download again, the percentage goes back to where it was.

I have just lost another downloads.dat file even though nothing appeared wrong upon quitting LimeWire. I copied away the .bak file and looked what might caused the problem. Upon attempting to read in that file I have found that the following exception is thrown:

java.io.WriteAbortedException: writing aborted; java.io.NotSerializableException: com.limegroup.gnutella.messages.QueryReply$PushPro xyContainer

I would suspect that there is something wrong with storing downloads via push proxies.