Direct Connect: Just These Guys, Ya Know?

No more fragmented downloads

It has already described in a previous post that how downloads work in DC++ and how the temporary files created and copied to the target path when a download finished. That post mentions two kind of possible methods of allocating the necessary disk space during a download :

• the “normal” method where disk space allocated continuously as the file being downloaded (more precisely when a particular amount of data – the size of the download buffer – is received);
• and the so called anti-fragmentation method which allocates the whole required disk space for the file before the actual download starts.

According to the DC++ changelog, the possibility of anti-fragmented downloads is added way back in version 0.241. Both methods has advantages and disadvantages : the normal method requires less disk space until the download has been finished but the file can be fragmented and it also can make the whole filesystem fragmented soon. With trying to allocate all the required space in one go, antifragmentation method result files laid on the disk more continuously. Also when the files moved or deleted later, there will be more long contiguous regions of free space left in the file system.

Besides the less fragmented file/file system, anti-fragmentation method has more advantages :

• It speeds up downloads (especially when downloading large chunks in high speed transfers);
• Downloads won’t stop because of a disk full error any more – if there’s not enough space they won’t start at all.

Up until the recent versions of DC++ it was the users’ choice what method to use as both of them worked well before segmented downloads introduced in DC++.

If you examine the recent lines of the changelog you will find an entry for version 0.706 saying ”Anti-frag no longer optional – not using it was broken by segmented downloading”. That means the anti-fragmentation method is mandatory from this version, due to the implementation of segmented downloads.

As we said before the only disadvantage of the anti-fragmented method is that it needs more free disk space for the temporary files. This can be some bad news for those DC users who often suffer from lack of disk space. From now, they should take more care of adding large number of files to the download queue. Many of you who use other p2p software should be familiar with this kind of behaviour though, as almost all of them work the very same way.

There is trick that may help to avoid this higher chance of running out of disk space. Its useful for those who have more than one hard disk/partition in their computer. From the DC++ built-in Help :

You can use %[targetdrive] for optional unfinished directory for all target drives. This way you can share the incomplete files among your drives which will result a smaller chance of running out of disk space.
Example : when %[targetdrive]DCUnfinished\ set as unfinished directory, DC++ will create incomplete files in E:\DCUnfinished\ when you download to any target folder located on drive E: and so on…
%[targetrive] option is also useful if you often download larger files to a drive other than where your usual unfinished directory resides. At the end of a successful download, moving a large file from the unfinished folder to its target could be very time and resource consuming, especially when moving files to another partition of the same physical drive.

Also good to know that with anti-fragmented download method, users may face a confusing error message “Could not open target file : Not enough space on the disk” more often. This error can happen only at the start of a download only and it means that the temporary file couldn’t be created. This can cause some confusion for those who isn’t familiar with the way DC++ download files. Unfortunately this is a general error message and it hints that there’s a problem with the target disk space. If the unfinished folder and the download target is not in the same drive this message can appear even if there are plenty of space in the target disk.

The last change is that as of DC++ 0.707 the name of the temporary file omits the .antifrag extension. Why? Because its unnecessary. We know that all of them are anti-fragmented and they always look like filename.ext.TTH.dctmp from now.

When stable become really stable

DC++ 0.707 has just out. Probably this version will be the first from the 0.7xx series which will be considered as a highly stable release – also hopefully a version that many user will feel safe to upgrade to. Altough the two previous versions also marked stable, both of them have a few rather serious problem so users of all 0.70x versions are encouraged to upgrade to 0.707 as soon as possible.

As you may know our client changed a lot over the last year, switching to a new, open source compiler and GUI library was a big step forward even in the ever-changing world of DC++. Introducing segmented downloads needed a lot of additional change and… caused some side effects as well. When DC++ 0.705 and 0.706 marked stable, more and more users downloaded and started to use these new versions and they helped a lot to find and fix a few more existing problems. Some kind bugs are hard to discover when a new version is used only by small group of testers so those numerous reports and feature requests from the community was really great. Now with 0.707 we reached a point where we hope that all the major problems are solved.

Along with several minor things the current GUI changes include :

• Search results with same TTH are grouped so from now so multiple results for the same file occupy only one row in the search results list. The ‘User’ column shows how many users share the file and their nicks can be seen in the right click menu.
• The annoying problem of spamming the finished up/downloads windows with all the finished segments is gone.
• From now you can copy the elements of the hub’s userlist to the clipboard.
• There’s a new quick access to all favorite hubs by a new drop-down menu in the toolbar.
• The built-in Help (and some important FAQs in it) are improved and a Get started guide added for beginners as well.
• Translations are greatly improved (thanks to the respective translators!), even a few more languages added.

Important problems fixed :

• A possible crash when resuming downloads in non-segmented mode.
• A security problem, where a remote client could crash your DC++, without you knowing or could do anything about it. (The issue hits all DC++ versions from 0.670 !!)
• Fixed a severe bug that keeps DC++ from returning correct search results for files and returns no results at all when searched for directories (bug exists from 0.705).
• Also fixed a problem introduced with 0.706 where resumed downloads can be corrupted if the temporary file deleted or if you try to resume downloads started with an older version of DC++.

So again, its time (and safe) to upgrade! As usual, if no serious bugs are reported, 0.707 will be marked stable within two weeks.

DC++ 0.706

Another version of DC++ is out. After 0.705 being stable, this version comes up with the primary fixes required by people on launchpad, and it’s getting closer and closer to the old interface functionality.
The most significant changes include :
You can now see if a hub/user is online/offline by the color of the icon.
The transfer color bars are back.
You can now share multiple folders under the same virtual name ( mixes the files ).
Every connection shows now on which hub it started.
Translations are more complete, we thank this way everybody who helped translating.
Among other multiple fixes, we hope this is the best DC++ version to the day.
The same thing goes, if no serious bugs are reported about this version, in two weeks it will be marked stable, so go ahead and download it from sourceforge and have a test. We await your feedback.