Opened 11 years ago

Closed 9 years ago

#4036 closed Bug (fixed)

Qt Client doesn't delete torrent files

Reported by: dancingrobot84 Owned by: jordan
Priority: Normal Milestone: 2.70
Component: Qt Client Version: 2.21
Severity: Minor Keywords: qt delete torrent file


Here is description:

  1. I open some .torrent file for the first time.
  2. Options dialog appears, I check 'Move torrent file to Trash', click 'Open'
  3. Everything's okay, torrent added and .torrent file deleted. But.
  4. I open one more .torrent file
  5. Options dialog appears, I check again, click 'Open'
  6. Torrent added, but .torrent file is still in a folder.

It happens when I open .torrent files using file manager (Dolphin) or using Chromium|Firefox after download. After restarting the client first added .torrent file succesfully moves to trash, but the others don't.

I'm ready to help if you need something else, for example, logs or screenshots.

And btw sorry for my English:)

Attachments (1) (519 bytes) - added by rb07 10 years ago.

Download all attachments as: .zip

Change History (6)

comment:1 Changed 11 years ago by rb07

Works when I do all the opening from the Qt client, not when done otherwise.

If I "open" by clicking on a link in Firefox, then the .torrent file is not deleted.

This has to do with file association, the code reaches AddData::set() where the test to see if it is a file fails. From there, since it wasn't recognized as a file, its not going to be deleted.

The 'key' used in AddData::set(key) is not a file path, it is the contents (converted to Base64 in ...

Last edited 10 years ago by rb07 (previous) (diff)

comment:2 Changed 10 years ago by Anonymo

I'm having this issue as well with a newer version. It's an issue with transmission-gtk as well in KDE, so it might just be a Dolphin problem.

Bug report with KDE:

comment:3 Changed 10 years ago by rb07

Found the problem in Windows: Firefox creates the .torrent file with read-execute permissions, when Transmission-Qt tries to delete it receives an "Access denied" error (i.e. no write permission implies no deleting).

I'm attaching a patch (against revision 13019) that solves it. Tested on Windows but should work just as well anywhere... I also changed to use the file name, not its contents, but I don't think this is part of the solution (it does improve the open options panel, now the name of the file appears, before it was blank).

Last edited 10 years ago by rb07 (previous) (diff)

Changed 10 years ago by rb07

comment:4 Changed 10 years ago by qwerty12

This happens in Arch Linux/KDE 4.8.4 because of Transmission. I checked ps while adding a torrent through Google Chrome (which is a GTK+ application and just calls xdg-open): argv[1] is correctly set as the torrent's file; it gets lost in Transmission somewhere. I took a quick look and in toBase64() is called for items that are of the filename type, like for metainfo. Why? In any case, changing it to a.filename.toUtf8().constData() solves it for me - the filename field actually contains a filename and the file gets removed.

comment:5 Changed 9 years ago by jordan

  • Milestone changed from None Set to 2.70
  • Resolution set to fixed
  • Status changed from new to closed

Patch added in r13447

Note: See TracTickets for help on using tickets.