Gnutella Forums

Gnutella Forums (https://www.gnutellaforums.com/)
-   LimeWire Beta Archives (https://www.gnutellaforums.com/limewire-beta-archives/)
-   -   Partial File Sharing in LW! (https://www.gnutellaforums.com/limewire-beta-archives/20821-partial-file-sharing-lw.html)

trap_jaw4 July 3rd, 2003 11:34 AM

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

sberlin July 3rd, 2003 03:04 PM

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.

stief July 3rd, 2003 04:50 PM

Thanks for the info and update.

jum July 4th, 2003 05:01 PM

Quote:

Originally posted by sberlin
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.

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.

barbas July 6th, 2003 03:08 AM

Quote:

Originally posted by sberlin
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.

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

sberlin July 6th, 2003 09:57 AM

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.

jum July 6th, 2003 01:04 PM

Quote:

Originally posted by sberlin
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.

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.


All times are GMT -7. The time now is 04:59 AM.

Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2024, vBulletin Solutions, Inc.
SEO by vBSEO 3.6.0 ©2011, Crawlability, Inc.

Copyright © 2020 Gnutella Forums.
All Rights Reserved.