[bug]downloaded file inconsistence

[Big Muscle 1]

it's not the exactly same as disk cache, but it's part of RAM which is used as extension to the disk cache. You should just read WinAPI, because when you write file to disk, it will stay in cache until system flushes all data to disk.

[amp 0]

Ok, how about Advanced resume using TTH. How it work in SDC now?

This thread is also related to the problem

http://forums.apexdc.net/index.php?showtopic=604

[Big Muscle 1]

Advanced resume using TTH is feature designed for non-multisource files only. It's something similar to rollback but via TTH leaves.

[amp 0]

And why it doesn't suite for multisource files?

[Big Muscle 1]

because there can be no data to verify. It allignes start position to TTH data block and then verify using TTH leaves whether you're trying to resume same file :P

[amp 0]

So, may it detect faulty blocks in the file being downloaded?

[Big Muscle 1]

no, it only checks first X kB when resuming whether the file is same.

It can't detect faulty blocks because they already has been verified and marked as ok, but your computer corrupted this information.

[amp 0]

Still, can't understand why you won't allow rechecking blocks. Its impossible to fix incomplete downloads now, for example, from another p2p client, like uTorrent.

At my point of view, in case of big file transfers through WAN (there even connection may be unstable), full file rechecking is a rule. Remember md5 hashes even for ftp on public servers.

[Big Muscle 1]

btw I found a workaround for this problem. It's flushing data using FlushFileBuffers before information about verified block is stored to queue.xml. But this can be too time consuming and can decrease overall download speed.

[void 0]

btw I found a workaround for this problem. It's flushing data using FlushFileBuffers before information about verified block is stored to queue.xml. But this can be too time consuming and can decrease overall download speed.

And even doing so would not help in all cases. Modern ATA drives store unsaved data in their own buffer even when OS thinks everything is already written. And, of course, buffer contents would be saved (or not saved) out-of-order...

[amp 0]

How about situation when seeder sends corrupted data? Bad client/blocking software or hardware failure on his side - this might happen for short period and you'll get faulty packet. I still think that full rechecking according to TTH is a must.

My queue.xml was wiped. I've restored download with old SDC version (1.0RC10). So now I'm downloading it. But everytime source appears online, new Strong (Apex too) is seeking something on HDD (for a couple of minutes) and only after that restarts download. FreeBlocks and VerifiedParts are not saved into the queue.xml.

I hope you will add some method to check and resume such downloads painlessly. Old methods won't work anymore .

[Big Muscle 1]

if uploader sends corrupted data then you will see message "TTH inconsistency", source will be removed from queue and block will be redownloaded.

Current TTH checking method catches every corrupted incoming block, because each incoming byte is checked against TTH tree before saving to your HDD.