share rehashing system should be updated

coded up this idea... here it is

Please create a patch against the head revision the way written in compile.txt...

I'd just like to ensure (I scanned the attached .7z file but it's hard to spot all the differences without an actual diff) that this doesn't break DC++ under WINE per the testing in DCDev Public. This appears to imply something akin to one of
(1) detecting WINE and falling back to regular share scans;
(2) keeping regular share scans and merely adding additional instant-file-addition/removal detection; or
(3) having a setting to disable it.

If the existing code already does something like this or functionally similar, that's great, but it's just tricky to determine for sure.

When dan posted this file in Public, he told me that after this code is applied, the client would try to keep hashing the file as soon as it detects it has changed.
For me it causes a problem.. For example what happens when you try to download directly into your shared directory? That may take hours, and if you do that, your client would try to hash the file in every x ms for hours? That sounds kinda ugly. Yes, I know: downloading to shared directories is not a pretty thing either, but sometimes it happens, and users do that.

@cologic: currently it does (2). i think the new code may even work under wine now actually, i changed how its done.

@Szabolcs Molnár: it may not be the prettiest solution, but it's certainly better than the alternative...

Szabolcs is right, we even have a function 'Share files instantly...' which initiates a rehashing after a download finished to a shared folder. Does your (still unseen) patch cope with this?

patch format version. i don't think this is actually more readable lol...

@eMTee: yes and no. it doesn't treat files downloaded into a shared folder by dc++ any differently than files downloaded into a shared folder by any other app. but it does instantly start hashing on completion.

patches are easier to merge with the source thats why we requested it :)

That patch seems to be very complicated for me. Especially those comments as "bad bad", "fixme: " or "FIX FIX FIX FIX FIX THIS. NEVER DEALLOCATED". I don't think it should be implemented in DC++ in such way.

well, the first couple comments were instances where something should have worked, but didn't and was worked around instead - i felt it was better to make a note of it rather than pretend it hadn't happened. as to the deallocation part, i'm honestly not sure how that should be coded within the existing dcpp::Thread framework, since it does need to be deallocated, but the thread would potentially still be using it as it gets deallocated... a simple join() wouldn't work as the change requests are blocking... so i left it as is for someone who knows more about it to take care of....