Big Muscle

if you don't have arguments against, you are trying to quibble. Hmm. Better don't say anything. I will write it in different words: THAT THING WON'T BE IMPLEMENTED BECAUSE IT WON'T HELP IN NEARLY ALL CASES. Now you understand it? Have you ever written a lot of source code??? If yes, then would know that something which would be useful in 1 of 100000 cases, is totally useless and it's no point in doing it. Btw just a personal question: You doesn't have more useful things to do than being all day in this forum and trying to force everyone to think that there is some bug in segmented downloading? Personal advice: If you, instead of being in this forum, try to find a cause of your corrupted files, then you won't need to write here anymore.

btw purpose of what I wrote and you didn't understand: if wouldn't have a bug in your PC then you wouldn't need any change in corruption detection routine.

So solution: - When I find why it crashes, I will fix the crash. - I will add a name (or at least TTH) of corrupted file to "corruption detected" message. and that's all. It will not erase and readd the file, because in 80% it won't help and users will not only complain that it deletes their files. These clever TTH leaves verification has been made to redownload only corrupted parts and not whole file (which will be corrupted with same probability as the first downloaded file). Btw, if you read my first post to your topic, you will find that I said it can be caused by software error too (not only hardware). Like in the past, ZoneAlarm caused corrupted downloads which resulted in infinite "Rollback inconsistencies" messages (only with normal downloading, not for segmented downloading!) and noone complained! They just uninstalled ZoneAlarm and everything worked then.

yes, it's the bug, but in your PC. We won't finish the file until all chunks are 100% correct. OK, let's say we stop redownloading after 10 tries. But what then? The only option is that you will delete the file from queue, because we don't let you to finish it with corruption. I'm only interested in fixing the crash during the download. You would be helpful if you have helped us to find the bug in code. And not only spread lies about bugs in segmented downloading.

I thought it, but your posts show something different :whistling:

Sorry, but redownloading of corrupted block is a bug??? Sorry, but we aren't such stupid to leave the corrupted file on your HDD so you could share it and spread this corrupted file over the network. every p2p client does the same if there's corrupted block, it will be redownloaded (in most of cases from different user, if there's any with free slot). It's only your problem that the redownloaded chunk will be again corrupted when it's saved to your HDD. We won't support this corruption and you must accept it, or you should go away from DC network, because we don't need the user who wants to spread corrupted files over the network.

Sorry that I must say it. But are you really blockheaded or just you aren't able to read what I have wrote to you in all of your threads ??? so again, !!!!!!!! ERROR OF HARDWARE HAVE NOTHING TO DO WITH SEGMENTED DOWNLOADING !!!!!!!!!! Now you are able to understand it?????????? And why normal downloading is accepted if it allows to leave corrupted files your HDD and allows to spread these corrupted files over the network (reason of having two many "same" files with different TTHs in the network). Segmented downloading allows only leaving and sharing 100% correct files. You are right only in one sentence - the corruption message should display also filename of corrupted file and maybe it will be changed to this way. And only one bug needs to be fixed - crash in FileChunksInfo. BUT IT HAS NOTHING TO DO WITH THE CORRUPTION BECAUSE IT CRASHES REGARDLESS THE CORRUPTION (understand that it crashes sometimes when there's no corruption and just you are the case that it crashes when there's corruption) NOW YOU UNDERSTAND IT??? Sorry for that but I really don't know what I should write to you, because if I writes anything, you will still say your rubbish as "there's bug in segmented downloading because I have corrupted files" etc :whistling:

there's nothing to fix. Bye.

No, it doesn't. It's true that there's some crash, my betatester reported it to me too. But he doesn't have any corruption. Just a crash. After restart, it downloaded file correctly. And Strong/Apex doesn't have any "corruption detection technique". I don't know why to call it technique. It's only logical operation to detect whether data on your HDD are equal to data which you have downloaded. If it doesn't, it redownload it. What should it implement more??? Should the scandisk/checkdisk be implemented in Strong. Should there be a HDD fixing tool implemented in Strong??? or what??? Just a question? Why Windows doesn't implement any "corruption detection technique" during file copy???

so explain why you are the only one with corrupted files???

but Strong/Apex redownload ONLY the corrupted parts of file.

sorry. I won't read it. a) it's too long I don't understand why you have created 4 same topics about the same problem c) Strong/Apex doesn't cause the corruption so write to your HDD/memory/OS manufacturer to provide you the tools for fixing the bug

you still can't understand that the problem has nothing to do with remote side? Data was downloaded and verified correctly if it is, it means that you have insecure computer. Some user is hacking your system and modifying files on your HDD now do you understand? better, corruption in the file "was created" when it had already been saved on your HDD and connection to the remote user had been closed. It has nothing to do with network communicating! how many users has corrupted HDD? maybe one of 1000 (maybe of more, just a guess). So I don't think it is worth wasting memory to save some counter for every chunk.

please, read my post above again. Or maybe I will try to explain it better. If you "corruption detected" message, it means that file was corrupted after saving to disk. So it was correctly downloaded and correctly sent to your operating system. If some remote user sends you corrupted file, it will be caught by "TTH inconsistency" and user will be removed from the queue. "Corruption detected" message has nothing to do with file transmitting from user to you. Or you could try to tell the solution which user should be removed in this situation. You download file from user A and everything is downloaded correctly (TTH leaf matches), so it is saved to disk. Then you want to download next chunk of same file from user B. Strong/Apex reread the already downloaded part of file from disk and detects that it's corrupted. Now tell me which user should be removed: user A ? but why? data from him has been verified and they were OK. user B ? but why? we didn't download anything from him yet.

Appendix: Windows itself don't have any mechanism against the corruption during file copying, so I don't understand why any other program should have it.

Too long text to read it. I don't have time for it. I still don't understand what you are trying to solve. It has nothing to do whether it is normal or segmented downloading. I said it many times. Segmented downloading doesn't allow corruption, that's the normal downloading which allows corruption. Because segmented D/Ling warns and redownload corrupted blocks, but normal downloading doesn't. I think I haven't told you what "Corruption detected" message means, so I will describe it: a) you are downloading some block of data it will be stored to Windows internal buffer c) Strong/Apex will send a command "write it to disk" to your OS. d) Then it verifies whether this data is OK d1) if it isn't, it will write "TTH inconsistency", remove user from queue and tries to download this block again. (jump to a) d2) if it is OK, it will continue downloading next block (jump to a) e) when some block is being resumed (not from its start position), it will reread the already downloaded part of chunk (which has been downloaded earlier using steps a,b,c,d,d1,d2) f) this read part of block is completely verified g) if it is OK, it will continue downloading of this chunk (jump to a) h) if it is corrupted, it will display "Corruption detected" and completely redownload whole chunk. So if you don't understand it, it simply means that "Corruption detected" messages informs you about some corruption which occured after data was saved to disk. It has been already verified before saving to disk and it was OK else you couldn't see this message.

it would be better if you had build Apex/Strong in VS as a Debug build and completely watch whole process - if it hits some assertion, what it writes in output window etc...

I tried to download all the files you have problem with. And I was in hubs you wrote. I've dowloaded them manytimes and always no crash, no corruption, TTH of downloaded files matched with the original.

there's no possibility to modify search terms in current protocol. You can use "-" in search term or use regexps in "Search in results" field, but both possibilities only filter the local results.

OS selects where the file be saved and i don't know how does it decided it. I just will try to fix the crash and you will see whether it will correct your problems. That's all I can do.

just a question. Do you use emulation for hubs above ? And from which users you were downloading from when it crashed?

i doubt that you had and you will always check TTH of downloaded files. Normal way just doesn't show the message and normally saves the corrupted file to the disk.

Yes, you are true. File can have correct TTH and can be 100% if it has been downloaded in other way than segmented. But again - it's only this situation. Let's talk there is some HDD error (just guess, it can be also memory error etc.). This error appears on clusters G and U. Current situation, user downloads file using segmented downloading and Strong/Apex tries to save them into cluster G. So what happens? Yes, file will be corrupted. Normal downloading saves the file to cluster A, so file will be OK. Another situation, user downloads file using segmented downloading and it will be saved to cluster J. So no file is OK! But later he wants to download another file using normal downloading and OS selects that it will be saved to cluster U. So where are we now??? File will be corrupted using normal downloading. I hope, that now the problem is understable. But I also realized another situation. The question is, when the corruption occurs. Before crash or after crash??? But time can't be detected, because Apex/Strong will report the corruption when it's detected, but not when it occurs. what I want to say: a) corruption occurs before crash -> so when it is detected, Apex/Strong wants to fix it and it crashes during fixing. This means some HW bug in the PC. corruption occurs after crash -> Apex/Strong crashes and file gets corrupted due to the crash (because OS doesn't flush to disk). Both situations mean that the crash must be fixed. But in A) it won't fix corruption messages. I know that now you will say "it's really situation ", but you can't say it, because it can't be decided ;)

Why you can't understand me? So again: Today you download file using segmented downloading and it gets corrupted. Two days after you will download another file using normal downloading and it gets corrupted too. Corruption doesn't depend whether you use normal or segmented downloading. It depends on actual memory/HDD position (according to where the bug in your PC is)

two options are missing - a) I got corruption errors but after fixing bug in my PC, they've gone and now everything is ok my PC had crashed to BSOD. After restart I saw corruption error, but corrupted part was redownloaded and file has been completed correctly. (this happened to me once)