Jump to content

.torrent file handling weirdness


Jade

Recommended Posts

Posted

I've got a bit of a gripe with the .torrent file handling and wanted to ask if that can be fixed. Here4 are my settings:

Store torrent files in:

G:\Shared\_Torrents

Move torrents for finished jobs to:

G:\Shared\_Torrents\done

I always download my torrent files first into "G:\Shared\_Torrents". As soon as I start a torrent in uT, the client creates a copy with the ending .1.torrent. When the download is finished, the latter file is moved to "G:\Shared\_Torrents\done" and renamed back to .torrent.

Now this is all fine (if somewhat annoying, bec. there is always a redundant torrent file on my HDD, which confuses me), but the *real* problem is that uT seems to *require* both files. i.e. if I delete the original file and restart uT, it is erased from the download list.

I reckon that's a bug, because uT is supposed to be relying on the copy (the .1.torrent file).

Is there a way of making uT work with the original torrent file only, rather than copies? It's also confusing if you say "remove & delete torrent file" and end up having the original file remaining on the HDD.

Thanks in advance for looking into this. It's just a small glitch, but it annoys me very much :(

Posted

That's because the presence of the original torrent file forces µTorrent to use a different name for the file. µTorrent always creates a copy of the torrent being used in its torrent storage file and associates that with the entry in the queue, so if you accidentally delete the torrent that was originally used to start the download, µTorrent can still continue the download. that's why there's the duplicate name. After the torrent is complete, it moves the work copy of the .torrent file to the finished folder.

What may be happening is that µTorrent might be renaming the original torrent in the storage folder and associating it with the queue.

Posted
µTorrent always creates a copy of the torrent being used in its torrent storage file and associates that with the entry in the queue, so if you accidentally delete the torrent that was originally used to start the download, µTorrent can still continue the download.

That makes sense, but it's still confusing to have two identical files, not knowing which one is the "active" one. Ideally, I'd love to have the "make a copy" behaviour as an option, rather than default.

Additionally, uT also creates a work copy of torrent files that I'm starting to seed (during the hash check) and that are 100% complete on my HDD. This doesn't make any sense to me in terms of the "continue to download" safety net you mentioned.

After the torrent is complete, it moves the work copy of the .torrent file to the finished folder.

If it does that, it should retain the .1.torrent ending to avoid any confusion.

What may be happening is that µTorrent might be renaming the original torrent in the storage folder and associating it with the queue.

The *older* torrent (with the original filename) seems to be associated with the queue. That's what I'd classify as a bug. Maybe uT is supposed to "fall back" to the work copy, if the the original file goes missing and just doesn't do it for some reason...

Posted

Seems to be fixed in 1.2. As far as I can tell there are no "work files" any more, uT now works with and moves the original torrent. Nice :D

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...