Big Muscle

I just can't understand why you can't understand that you have bug in your PC. There can't be any switching, because it's useless. Maybe file ABC gets corrupted in segmented downloading but it's ok for normal downloading. But file RKX will be corrupted only for normal downloading, but you won't see any message informing about corruption. Same thing will happen when you will copy file ČŘ

Such workarounds will never be implemented - just its not the workaround, because the same problem can appear also for non-segmented downloading: a) but you won't see any message about corruption and file will leave corrupted on your HDD it will appear in another time than for segmented downloading. Or better, it will appear when your PC/OS wants to access to the corrupted area. User should fix his problem on its own.

a) it's already there yes, I will fix the crash. But you will still get messages about corruption until you fix the problem in your PC.

The crash is the program fault, but the file corruption is some other HW/SW failure

DC++ and SDC+/ApexDC++ are completely different applications: a) DC++ checks TTH tree only and does something during resume, so there's only minimum chance to figure out that the file is corrupted StrongDC++ has different download techniques than DC++. It means that StrongDC++ accesses different HDD/memory areas, so it can walk into some corrupted part in different time than DC++.

I don't see any benefit in it. Why can't you just disable segmented downloading in the settings?

The crash must be caused by that corruption. But that corruption must be caused by some failure in your PC.

put your HDD into the trashbin, because it's corrupted. If you manage to hash these files, they will be corrupted!!!

Does it do a mess for all users or only if the segment is downloaded from one certain user? Have you tried downloading other big file if it downloads ok?

any kind of software protection would write "Error reading/writing blahblah...". CRC error means physical corruption. He should not try only reading the file, but completely move it to different disk (not only to different folder)

At the weekend, I'll try to reproduce the crash and will try to fix it.

CRC errors are caused by impossibility of reading file from the disk.

When does this exactly happen? I'm trying to fix this crash for a long time but without success My betatester was running the last beta version of StrongDC++ for 5 weeks without any crash/hang. But after these 5 weeks it crashed with this exceptioninfo :(

you can't set chunk size I think that valknut can use $ADCGET to download by chunks (that's why you see [C]) but it's not able to upload by this way, so we must use non-chunked way of downloading from Valknut.

In the past, there as the only command to download some file. It was $Get command and the only possibility was "download file X from position Y" and that's all. That's why DCGUI implemented improved $Get command which is able to "download Z bytes of file X from position Y", but this command works only if it's implemented also in remote client - that's identified with CHUNK in $Supports. Later, DC++ implemented $ADCGET command which is able to "download Z bytes of file X from position Y" (same as extended $Get in DCGUI) but is able to do more things (like downloading TTH tree etc.) and is extendable. Currently, both ways of $Get command are obsolete and it is recommended to use $ADCGET command which is much better.

no, it doesn't slow you downloads, but it makes it faster, because a) you MUST upload in every situation, because you wouldn't able to download (it doesn't matter what you upload) this also happen for other users, so you can download another chunks of the file from these users, so you have more sources you can disable it by disabling multisource downloading

filelist isn't downloaded for any file it's downloaded for the user's share list

any hammering is bad :stuart: regardless the type of disconnection

how can you be 100% sure that the user really disconnected you and there's no connection problem which would cause the disconnection?

last version is VC8, so I doubt there would be some version #11 of its library :)

yes, ADC provides GFI command (GetFileInfo) :)

you can, but you have no way how to transfer this info between clients (for example in search) and if this info will be available in your filelist, then your client will be banned, because filelist will be too large.

yes, everything is corrupted. You moved everything away, but queue.xml still contained old stored paths, so it continued downloading to old place. You can't do anything now.

it's not the good solution. Look at the code above sc = ::StgCreateDocfileOnILockBytes(lpLockBytes, STGM_SHARE_EXCLUSIVE|STGM_CREATE|STGM_READWRITE, 0, &pStorage); if (sc != S_OK) { lpLockBytes = NULL; } now you should check what value is stored in "sc" when it crashes.

and that's the reason why I've already fixed it :crying: