linuxdcpp-team team mailing list archive

[eMTee <1194085@xxxxxxxxxxxxxxxxxx>]

Yes, the source doesn't get completely removed instead of only getting flagged if the file is larger than MAX_SIZE_WO_TREE just like in case when there's no full tree provided.
Theoretically you could introduce a new flag for our case which would behave the same - I just don't think it worth it because the problem is the same: we cannot check the finished download against the full tree because it's not available at the time of the checking (cannot be read from the hash database since it's not saved). In my thinking these are similar enough cases to use this flag to solve the problem of flooding.

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

Title:
  Infinite download loop for a single tree

Status in DC++:
  Confirmed

Bug description:
  It goes as follows:

  1. DC++ tries to save a downloaded tree in hash data but the data file isn't writable.
  2. The client searches for other downloads from the same user and finds the same file again.
  3. The client can't find the tree for that file and downloads it again (back to step 1.)

  While the problem happens relatively rarely on Windows, it's much more
  common with Linux clients. Even though there's a log message when the
  writing fails, it seems that users don't generally notice it, which is
  why some users have even requested a feature for banning IP addresses
  from the client (and I've also seen users downloading the same tree
  from me for several hours).

   I've fixed this issue in AirDC++ 2.50 by catching the database
  exceptions in DownloadManager::endData, forwarding the error to the
  connecting item and changing the item to a state where it will connect
  only when the user manually forces the connection.

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