Wow, PFS work in LW! In the 3.1.0 jum170, build at least. It's great news, the only problem is that I upload mostly to Shareaza users, and I don't want to, but I guess it's normal, since they're supporting PFS. Looking forward for leechers' sharing! It should help the network.

Glad you like it. If you look closely, you'll notice the files in the incomplete folder have turned from red to black indicating they're being shared, and contain the same stats as shared files do.

Works well here too. While checking for upload stutter, PFS started an upload to a LW 3.1.0 of a file I was downloading. Congrats

the 0k incompletes are also shown in black. Would this be because they're sharing info like alternate sources?

Will it do any good to load old incomplete files into the incomplete folder if the original downloads.dat file was lost?

Technically the incomplete files are shared the second they're created (assuming the user has allowed the sharing of partial files and the queryhit has given us a hash of the complete file). For zero-length (and other small files) this allows alternate locations to be exchanged. Realistically, you will only receive requests for the file after approximately 25% of it is downloaded (or 5MB, whichever is larger). This is because you will not insert yourself into the 'download mesh' until that threshold is reached. We're looking at tweaking those numbers.

Not all files in the incomplete directory are shared -- only those with an associated entry in downloads.dat. This is because we limit partial file sharing to requests by hash in an effort to reduce corruption. You may also notice that if, for whatever reason, the "Your download is corrupted" message appears while downloading, then the incomplete file will be unshared (and hopefully turn back to red).

Ah--thanks for the info.

Could the T-number (the #of bytes to be downloaded?) of the incomplete file be used to lookup the original hash to be reinserted into the downloads.dat?

let me know if TSQ (that's a stupid/silly/shitty question)!

In order to generate the needed hashes, you need every bit (literally) of the file. The number after the T is simply the size of the completed file. The reason the hash is not included in the filename of the incomplete file is because some filesystems have limitations on how long a filename can be, and hashes are long.

OK. Trying to resume old incompletes would not be a good idea then or in the future, once the downloads.dat file is suspect or deleted.

So, anyone with really old incompletes should just be advised to save themselves and others grief--remove them.
. . . and to ignore any search results that start with the Tnumber?

I guess I was thinking PFS might also mean additional PF recovery. Of all p2p programs I've tried, LW is the best at resuming incomplete files. It's so easy to forget what a pain interrupted downloads used to be less than a year ago!

LimeWire does not match queries against incomplete files. (Meaning that the numbers in the 'hits' column should NEVER go above 0 when looking at the incomplete directory.) If you see a result with a T-# when doing a search, it is because someone has actually shared their incomplete directory.

Ah, our prayers have been answered. Although I don't have anything partially dled (I deleted all my incompletes), it sounds here as if it is working.

This is so fantastic. Leechers will be forced to at least partially share. The entire gnutella network could really get a huge boost from this, content wise and user wise.