Jump to content

1.7 RC2 2999 Way-too-long-to-delete bug


Honeyfrog

Recommended Posts

Dragged-n-dropped in a torrent, hit OK on the save-wherever dialog, then realized that the save directory was wrong, and immediately hit red-X. Then I dragged-n-dropped again...and got "The torrent you are trying to add matches a torrent currently being deleted". Wait; try again. Same error. Wait; try again. Same error.

It took more than twenty seconds for the darned alert to stop appearing.

(I don't have pre-allocation, and I hadn't downloaded anything from any peers before "X"ing.)

Link to comment
Share on other sites

Ok, just looked into this some more. The warning was added to handle really bad cases with the asynchronous deletes (which is probably not the case for you), but also makes sure that you properly disconnect from trackers before connecting again with the same infohash, which is probably a good idea, although not doing so wouldn't be catastrophic. On the bright side, while looking at this, I found a simple optimization that could speed up deletes for those that delete .torrent and/or data =)

Link to comment
Share on other sites

@Honeyfrog: Several people experienced delays when deleting torrents in 1.6 (myself included), so it was a very real problem. The interface simply hung for a long period of time, and it looked like it froze.

Edit: Richard's optimization should have made it into RC4.

Link to comment
Share on other sites

(Testing using RC4 now. Problem is easier to notice when testing a torrent with lots of trackers, like a dozen or more.)

The warning was added to handle really bad cases with the asynchronous deletes (which is probably not the case for you), but also makes sure that you properly disconnect from trackers before connecting again with the same infohash, which is probably a good idea, although not doing so wouldn't be catastrophic.

Presently, uTorrent takes longer to X-out a single torrent that it does to quit entirely (at least far as the TaskManager is concerned) from a state or over a dozen torrents actively trading. (Does quitting just "heart-attack" the connections?)

Link to comment
Share on other sites

Quitting forcefully exits everything if it doesn't finish within 10 seconds after the user requests for the application to exit, that is, unless bt.graceful_shutdown is enabled, in which case it can take forever (it'll wait for a bunch of stuff to finish and trackers to respond properly before fully exiting with that option on).

Regarding the RC4 link I posted, I'm not really sure if it contains the fix, as the linked version is only build 3166, and IINM, Richard's change should've been incorporated after that (as the changelog shows, by build 3170).

Link to comment
Share on other sites

My aforementioned fix did not handle Honeyfrog's specific case, but it was something I noticed while looking at the code. Typically, the disk cleanup takes longer than the tracker cleanup, but in some cases (like with many trackers), the tracker cleanup can take longer. My fix was to allow file deletes before the tracker cleanup is completed.

For Honeyfrog's case, I have just checked in a change that will allow you to re-add a torrent that was just previously for delete, as long as you aren't waiting for disk operations with that torrent.

Link to comment
Share on other sites

One of the frequent Vista complaints is that it takes much longer to delete files than it did on XP. I don't know what the root cause of that is, I don't run Vista.

In the absence of any hard information, I suggest that Richard's change needs to be well tested on Vista.

Link to comment
Share on other sites

One thing that can happen is that you begin downloading a large file, like 1GB or more. Unless you have sparse files enabled, the first write to the file will take a LONG time since Windows needs to go off to fully allocate it. If you try to quit in this time interval the process will be in a complete limbo, the kernel won't let it terminate until the write is finished. If you try to start another instance of uT it will detect the previous one and refuse. You also won't be able to kill the process from task manager, or at all in any way. If you start a torrent, then quickly remove it while Windows is doing the allocation the deleted torrent is stuck waiting before it can really be removed. While in this state you can't add it again, at least not with the same infohash. Terminating uT won't help either - the process will still be in End Now Hell.

Link to comment
Share on other sites

One thing that can happen is that you begin downloading a large file, like 1GB or more. Unless you have sparse files enabled, the first write to the file will take a LONG time since Windows needs to go off to fully allocate it.

And that's another reason I want this l'il baby right here: http://forum.utorrent.com/viewtopic.php?pid=258475

If you think 1GB is a killer, uTorrent can and will choke/Error while allocating a full DVD9 iso, to say nothing of a complete 24gig HD project. :-P

Q. If sparse files _and_ first/last are simultaneously enabled, will full-size files still be pre-allocated? (I gotta have first pieces...last ones I could care less about, since about the only files that save important crap at the end are Microsoft junk like .wmv formats that no self-respecting ripper uses.)

Link to comment
Share on other sites

Thanks, Richard. Here's one thing you may wish to look into, however:

1. Start up a torrent with a dozen or so trackers (more the better, esp. if some bad).

2. Let it run enough to allocate some files.

3. Now remove+delete.

4. Immediately click the minimize tab.

--uTorrent acts like it's frozen for about five or ten seconds or so. Appears to be harmless, but it's disconcerting if you want your window space back pronto. (This may not be noticable on newer machines, but it's obvious on a Pentium III.)

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...