linuxdcpp-team team mailing list archive

[LoRenZo <919424@xxxxxxxxxxxxxxxxxx>]

Ok, it seems that it does not work as flawlessly as I described
previously.

First, I would like you to know that the first time I have started this build after the upgrade, the loading screen was stuck at the "loading hash data" for about 3 minutes. (The memory usage was around 10 MB during this, so the client was rather in half way through the  startup state at this point - I guess it is a normal behaviour based on the newly implemented changes.)
After this I have initated the /rebuild command which cleared up the expired entries as I already mentioned in my earler post.

I just did the reproduction steps based on this report, which you were
looking for to have confirmed.

I have added a new folder, and waited until it was fully processed by
the hashing procedure. I have removed it from the share and issued a
/rebuild. Once it was compelted again, I had to conclude that the entry
was still to be found in the HashIndex.xml. Since my older entries,
which were cleaned up in the first place belonged to a currently non-
existing path, I have tried to rename the folder and see what happens
after another rebuild. The entry was still in the file - though there
were some changes to its size. (Note that nothing has been added to or
removed/completed from the download list meanwhile). Afterwards, I have
moved the folder to a different location, rehashed the data, rebuilt my
list, but the previous entry was still there. I have removed the newest
entry after this and issues another /rebuild command. No changes were to
be found after all this.

Since the first startup took longer, I gave it another try (restarted the client). The time required for the startup was slightly less than before, and the files were still listed in the HashIndex.xml. (Note that there has been no /rebuild issued at this point).
Once the client was started completely, I have double checked the share information to see whether the newly added folder is listed there or not - but of course it was not therem since I have removed it prior the restart. After this I gave the rebuilding another try: once it has been completed I found that the newly created, expired entries are removed completely once again.

In conclusion, it seems that a client restart is required before the
/rebuild command can be made to work properly.

Additional note: during my current  trials I have always seen the "Hash
database rebuilt" notification in the System Log, too, and I have also
experienced some changes regarding the involed files' sizes.

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/919424

Title:
  /rebuild does not update HashData

Status in DC++:
  Confirmed

Bug description:
  BCDC 0.790a. 
  Windows 7 SP1 x64.

  Summary:
  If you add a new share, hash the files, and then remove it, issue a /rebuild and then re-add the same share again, DC++ will not rehash the files. Furthermore, a /rebuild between adding/removing shares does not change the size of hashdata.dat or hasindex.xml.

  Repro:
  * add a new share. accept the default name. DC++ hashes the files.
  * open your filelist to validate share is present.
  * check the size of hashdata and hashindex.
  * remove the share you just added.
  * issue a /refresh and /rebuild.
  * note the size of hashdata and hashindex has NOT changed.
  * add the same share again, accepting the default name.  DC++ does NOT hash the files.
  * issue a /refresh. DC++ does not re-index the files from that share.

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/919424/+subscriptions