BUGS: Torrent data directory collision

[BrandyLova]

Hi,

I recently encountered two related bugs which cost me a completed 600+MB download. They are both design flaws in BitTorrent version 7.2.1 build 25302.

The first bug is that if two torrents are different swarms (different infohashes) but have the same name, when adding the second one, BT will by default use the same data directory as for the first, since the directory is simply named by the torrent's name. No check is done to see if the directory already exists, and as such it is very easy in this case for the user to mistakenly have both downloading into the same directory, which is both messy and can cause serious corruption as well as set up for data loss when combined with the second bug.

The second bug is that, when asked to delete the data of a torrent job, BT just indiscriminately removes all files in the directory the job is set to download into, regardless of whether the files are actually part of the job or not. I realize this is just a programming short-cut, but it can cause data loss when combined with the first bug.

Here is how these two bugs together caused me to lose all data for a completed job:

I had two torrents of differing infohashes which were of the same name and essentially the same data. I chose to run both jobs in order to better assure that I could get the data, since one or both swarms may have been "dead". I was working with many torrent jobs and did not notice that these two had been set by default to download into the same directory. One never got far but the other finished after some painful waiting.

When I have redundant jobs running I will, when one finishes, ask BT to delete the data for the others, since BT allocates disk space in advance and so significant space is taken up by these redundant copies even though most of the data hasn't been downloaded. Not thinking that doing so would also delete the data for the finished version, I asked BT to delete the data for the dead one. You can imagine my frustration when a day later I went to use the data in the finished one, only to find it gone.

To prevent this sort of tragedy in the future, BT's behaviour should be changed in two ways:

1. When adding a job, prior to placing that job in a given directory, BT should check if the directory already exists, and prompt the user as to what to do in this case. The user should be given the option to append a numeric suffix to the name. Obviously in order for this to be of use in preventing collisions, the directory would have to be created immediately (or else the collision will not be seen until downloading actually starts); I think right now BT doesn't create the directory immediately.

2. When deleting the data for a job, BT should delete only those specific files it knows to be part of the job. (As an added caution, it should know whether it is a .!bt or the complete file that it should be deleting.) Of course, this means directories can't always be removed, if other files exist in them. While this might seem excessive, most uninstall programs under Windows already do this same thing for the same reason (to prevent unintended deletions).

I hope these will be regarded as bugs as opposed to feature requests, since although I realize BT was acting as designed, the design failed to consider the possible data loss implications of its actions.

If possible I hope someone can let me know when this issue is likely to be fixed, as I can easily foresee accidentally losing more data this way, considering how many torrents I've come across with the same names but different infohashes.

Thanks,

Kevin