TheSHAD0W wrote:
Here's a possibility for you, though; if you run scandisk, or chkdsk /f, it will be able to resurrect those files. I'm not sure of the exact procedure for the new Windows OSes. Figure out which FILExxxx.CHK is which (they may be longer than your desired file size, rename it, then resume using that file.
That's totally true, but you must run scandisk before doing anything else that could mean writing to the disk unit where the lost file is, otherwise you'll lose that file.
dill wrote:
With that Scandisk idea, I understand the principle of it, but I always thought scandisk recovered stuff had a lot of other corrupted stuff in it (thus the extra space), did you come up with that idea on a principle or have people actually done it.
I've done it many times, and since shad0w's client doesn't pre-allocate by default (unless you specify it in advanced preferences), the small extra space that may appear is just considered junk and there's absolutely no problems. Back when I used the experimental client, sometimes I had to cut off 2Kb of the recovered file because it refused to resume a file larger than the one it was told to download. Those 2Kb were there because scandisk doesn't know the exact size of the file, so it fills up the recovered file to the next FAT32 4k boundary (and since .avi files are always (?) divisible by 2k, I got always either exact size or 2k too big).
dill wrote:
oh ok, so to actually assign space to a file it needs to be closed and re-opened.
Yes, but if you don't have the complete file preallocated, any extra space taken on resume would also be lost after a crash (though Scandisk would fix it more easily, you wouldn't need to check for .CHK files). To make sure that no more crashes will disturb your download, preallocate before closing, and then resume.