share rehashing system should be updated

Bug #674816 reported by dan
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
DC++
New
Wishlist
Unassigned

Bug Description

currently the share rescan/rehashing system is designed such that it re-scans the entire directory tree after a certain amount of time. instead dc++ should use the ReadDirectoryChangesW windows API command to be instantly notified by windows when files are created or modified, removing the need to scan entirely except for on startup. see http://www.codeguru.com/forum/showthread.php?t=436716 for a simplified code sample.

eMTee (realprogger)
Changed in dcplusplus:
importance: Undecided → Wishlist
Revision history for this message
dan (dumbledore3) wrote :

coded up this idea... here it is

Revision history for this message
eMTee (realprogger) wrote :

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

Changed in dcplusplus:
status: New → Incomplete
Revision history for this message
cologic (cologic) wrote :

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.

Revision history for this message
Szabolcs Molnár (fleet) wrote :

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.

Revision history for this message
dan (dumbledore3) wrote :

@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...

Revision history for this message
eMTee (realprogger) wrote :

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?

Revision history for this message
dan (dumbledore3) wrote :

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

Revision history for this message
dan (dumbledore3) wrote :

@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.

Revision history for this message
Toast (swetoast-deactivatedaccount) wrote :

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

Changed in dcplusplus:
status: Incomplete → New
Revision history for this message
Big Muscle (bigmuscle) wrote :

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.

Revision history for this message
dan (dumbledore3) wrote :

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....

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.