Jump to content

Bug found in auto-load feature - existing file bug


Recommended Posts

I think I found a bug in the autoloading feature of utorrent.

In my current configuration; I have specified unique directory paths for all options that require the user to specify a folder.

I have several torrents in the auto-load folder, which have been renamed to .loaded, have

been partially downloaded, but are not yet complete.

copy <basename>.loaded to <basename>.torrent in auto-load directory.

BUG: Try to use the option "Remove And" -> Delete .Torrent + Data, but it fails. The item is removed from the listing in utorrent and downloading stops for that session, but both the .torrent and .loaded are kept unmodified in the auto-load directory, and all the previously downloaded data is still kept.

Close down utorrent, and restart. The .torrent is autoloaded, and the cycle continues.

The first bug here is that the removal function fails.

I think there is also a 2nd bug, which is that the auto-load feature is failing itself to rename the .torrent file to something else in the case that there is already an existing .loaded file.

Let me know if you need more of a description of any of this, or have any questions.

I have been successful in replicating this bug.

To fix the problem, I exited utorrent, deleted the .loaded files, restarted utorrent, then the "remove everything" feature worked as expected.

Link to comment
Share on other sites

I think your being a bit too quick with your insult trigger finger.

I have the impression that either you did not completely read my problem description, or you did not understand my poorly worded explanation of the issue.

Let me give you some more specific details, and please, try to stay open to to possibility that the issue might not have been caused by my stupidity.

(NOTE: I did search the forums on this issue, and I did find and read the other auto-load bug reporting posts. Those were caused by users using a single directory for two different option, but that does not apply here, as I'm not doing that. As I said in the original post, I am using unique directories for all options that require a target directory to be specified).

To help you understand WHY what I did was not stupid, I need to give you some background details on the source of the torrents I'm using.

The torrents I'm downloading are provided to me via a private torrent tracker/website pair (a closed/private/dark P2P net), and each torrent has a "key" in it, in the form of a directory path within a portion of the announcement URL, that links the torrent to my account on their system. All my torrents from this site use the same key within the URL, it is a "shared secret" used for authentication of myself to the tracker (this allows the site operators to remove an account, which invalidates the key, which causes the tracker to reject any attempts at downloading anything using the now invalid torrent.)

I changed my key (my reasons for doing so are not important, just trust me when I say I had a good reason), which had the effect of invalidated all the torrents I had previosly downloaded from this tracker. (this is by design, this was the effect I wanted).

My account is still open, but my key is now different. The shared secret has changed.

But I had a few incomplete downloads that I wanted finish, but now I need new .torrent files.

For all the downloads which were not completed, I chose the option to remove the item, and delete the .torrent file, but keep the partially downloaded data.

I then downloaded new .torrent files, containing my new, valid key, into the auto-load directory.

uTorrent finds it, and does successfully use the partially downloaded data to resume the torrent download.

So everything appears to be going fine, but the seeds for a a couple of the downloads dropped off the face of the net before I was able to complete the download. After a week of not seeing a seed, the private tracker automatically invalidates the torrent for everybody on the system.

So now, because of error messages from the tracker I see in utorrent, I know my partial downloads are never going to complete, as the tracker now refuses to work with that torrent.

The .torrent and the partial data I downloaded are now useless, but the "remove .torrent + data" option fails to perform the advertised function because of the existing .loaded file. The .loaded and new .torrent file were identicle, except the announce URL was different.

I successfully recreated this issue by doing a "copy" of the .loaded file back to a .torrent (which I admit, is a stupid thing to do in normal circumstances, but this was done for troubleshooting purposes, as an attempt to recreate the bug, and was not done as typical user behavior).

I said I copied the .loaded file to .torrent in my original message because that is a simple means of recreating the issue/bug I had. That was not what caused me to originally expereince the bug with the .torrent conflicting with an existing .loaded file in the auto-load directory.

If I am still stuipid, please clarify why. The FAQ entry you pointed me to (which I had read before making my original post), does not seem to apply to this situation.

Link to comment
Share on other sites

Try to ignore Firon when he gets like that. He has a stressful job :P

I did not take his stupid comment seriously or personally, I know I'm not dumb, even if he does not know it yet.

My primary concern is only that the bug gets acknowledged, and eventually fixed.

I also admit there were some key details missing from my original post, which I think helped give the impression that I was doing something unreasonable and/or dumb.

Link to comment
Share on other sites

µTorrent copies the .torrent that's auto-loaded to %AppData%\uTorrent, and renames the one in the auto-load folder to .loaded (or deletes it if you turn on the appropriate option)

Also, use the beta. And you don't have to re-load a torrent when you change your PID, just change your PID in the announce URL

Link to comment
Share on other sites


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

  • Create New...