Comment 13 for bug 919424

So was this ever fixed? Because here I am all these years later using 0.867 x64 (portable) on Windows 10 v1709 (16299.371) and I'm experiencing the exact same issue.

I don't know whether HashData.dat is being cleaned of invalid entries or not, but certain invalid entries are definitely NOT being purged from HashIndex.xml no matter how many times I issue a /rebuild or restart the client.

These are entries for files that have been renamed (in some cases I have 3 sets of entries with the same hash because I happened to have renamed the files twice). There are also entries for dummy 0-bit files that I create as fillers in directories to indicate missing or future files in a series. As and when I have the actual files in hand I naturally get rid of their corresponding 0-byte substitutes, but their entries are never purged from HashIndex.xml.

I think the common link is that all older invalid entries have hashes that are still valid. Let me explain with a couple of examples:

1) I rename/move a file - Now there are entries for the old name/path with hash XYZ and for the new name/path with the same hash XYZ.

2) I delete a 0-byte dummy file and replace it with a non-zero byte actual file. However there are still other 0-byte dummy files left - In this case there are entries for the old 0-byte file, and for the new actual file.

In both cases during a HashData/HashIndex rebuild DC++ refuses to remove invalid name/path entries purely on the basis of whether their hashes still match valid entries, and NOT on the basis of whether the file with that name or path actually exists or not. This is obviously the wrong approach. FIRST the file name/path should be checked for existence and if that test fails, DC++ should blindly purge the entry. ONLY if that first test passes should the hash then be checked and updated if required during a rebuild.

Given the numerous advantages of having a slimmed down Hash DB sans all invalid entries, please implement this change/fix ASAP. Thanks!