linuxdcpp-team team mailing list archive

[Jacek Sieka <655854@xxxxxxxxxxxxxxxxxx>]

Hm, the question is whether this is a feature or a problem =) Perhaps it
could be made into a feature by being realtive to the users home folder,
or possibly documents...any opinions? On the other hand, what's the
value in specifying it relative? Porting the queue between users?

In any case, there's no reason not tu support unc paths although care
should be taken since they can be 65k chars long...

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

Title:
  DC++ accepts relative path for download directories and it can cause assertion failure and other problems

Status in DC++:
  New

Bug description:
  #1 finished download directory

While the current DC++ gui (QueueFrame) can handle only absolute path's starting with <drive>: the lib accepts relative ones for the Default Download Directory setting. If you specify relative or UNC path for default download directory they pass QueueManager::checkTarget and then cause an assertion failure in QueueFrame line 457. 
After a download finished in a release build UNC path causes a temporary freeze and the file stucks in the unfinished folder. In case of a relative path set for downloads the file will be created relative to the  directory which was current when the DC++ executable started. This can result creation of downloaded files/folders in arbitrary places of the file system.

#2 unfinished download directory

The setting accepts relative path as well and there's no any further path check in this case. So the actual path where the unfinished files created (QueueManager::setFile) will be relative to the directory which was current when the DC++ executable started (which is not necessarily the program directory). This can result creation of Incomplete folders in arbitrary places of the file system and can reset unfininished downloads between sessions.

Thanks Thor for reporting issue #2 which led to further investigation of this problem.