Enable resume/find sources button with "Try Again" caption for files with the status es Complete and File Corrupt. In the latter case you want to reattempt getting it, preferably while the source is still online, and should not need to explicitly search for it. In the former case, the file might prove on examination to have been substituted with an ad or other junk, or otherwise damaged without the damage being detected resulting in File Corrupt status. In that case you want it to delete the file and attempt to get it again, but you might want to block the host that sent the bogus/substitute file so you have greater odds of getting the real McCoy next attempt. (There's some files I've been trying to get for ages that turn up frequently in search results but never seem to download right -- one I've gotten six or seven times and it's never shown a status of File Corrupt, but it's also been broken beyond use in every single instance!)

This brings me to another matter: finer grained detection of corruption. Really, each time a chunk of file arrives and the progress meter notches forward a bit, it should be possible to check that one chunk against some check bits tacked onto the end and rerequest just the one chunk if it's damaged. This will reduce accidental file corruption to nearly nil without having to reget entire files, only pieces. That leaves intentional corruption by hostile nodes that join the mesh for a file and send garbage or advertisements, corrupting and vandalizing the file. This is simple -- all files participating in a mesh need to have the same exact file, with the same SHA1. When downloading from a newly-discovered source begins, Limewire can request a random chunk of the file that it already has and compare it with the version it already has of that chunk. If the new chunk doesn't match and does have proper check bits, it's probably a hostile node trying to pollute the download, and should be dropped rather than downloaded from. Your node also won't refer other nodes to the hostile node. If it matches, it then requests chunks it does not have from that source in order to download part of the file from it. Downside is, if the first source to send any chunk of a file was hostile, it will download from only the bad actors! But at least the mesh for a file with bad nodes in it will get divided into two disjoint chunks, one sharing a bogus file and one the real file, and if you got the right one to begin with you will get the entire correct file and not a partially corrupt file.

This could also use Bitzi-like reputation management features, in which not only whole files but just chunks have reputations. The version of a chunk with majority representation in the mesh might rule; or volunteers can preview chunks (for some formats this should be possible) and vote them up/down.