Opened 7 years ago

Last modified 7 years ago

#6069 new Bug

issue with renaming torrent

Reported by: DaRieck Owned by:
Priority: Normal Milestone: None Set
Component: Transmission Version: 2.82
Severity: Normal Keywords:


When renaming a torrent (eg. with the torrent RPC rename_torrent_path) and the torrent directory structure looks the following:

- directory: 'torrent name'
    - 'original file name'.<file_extension>
    - 'original file name'.<file_extension>.jpg

It seems that the renaming of the torrent is not executed correctly. While downloading the renaming caused the structure to look like this:

- directory: 'torrent name'
    - directory: 'new file name'.'file_extension'
        - jpg.part
    - 'new file name'.'file_extension'.part

When downloading is finished and the files are moved to the download folder (incomplete-dir-enabled=true) the file that had been renamed is not even there anymore.

The rpc was called as following:

rename_torrent_path('torrent_id', 'torrent name'/'original file name'.'file_extension', 'new file name'.'file_extension'

I tried setting the incomplete-dir-enabled to false, but it does not go correctly then either. The files (jpg.part and 'new file name'.'file_extension'.part) are not renamed.

A small side effect of this is that when looking via the web interface, selecting the torrent, clicking on the info-button and then on the 'Files'-button does not show anything.

Please investigate.


Attachments (2)

torrent (941 bytes) - added by cfpp2p 7 years ago.
data for torrent name torrent
torrent name.torrent (281 bytes) - added by cfpp2p 7 years ago.

Download all attachments as: .zip

Change History (9)

comment:1 follow-up: Changed 7 years ago by DaRieck

I'm not really a C-developer, just trying to help the investigation going.

in torrent.c @ line 3667 there is the following code:

if ( (len == oldpath_len || (len > oldpath_len && name[oldpath_len] == '/')) && !memcmp(oldpath, name, oldpath_len))

Should the memcmp-command not be called with the length of the longest variable? If the oldpath_len is less then the length of name and the content is the same for that oldpath_len it causes issues I guess.

As in the example above:

'torrent name'/'new file name'.'file_extension'
'torrent name'/'new file name'.'file_extension'.jpg

comment:2 in reply to: ↑ 1 Changed 7 years ago by cfpp2p

Replying to DaRieck:

...just trying to help the investigation going.

You have posted the bug as Version: 2.82 however the code you reference is r14317 and only exists in trunk 2.84+.

comment:3 Changed 7 years ago by DaRieck

  • Version changed from 2.82 to 2.84

Ugraded to version 2.84 (14307). Still having the same problem. How can I upgrade (on debian) to 2.84+ (r14317)?

comment:4 Changed 7 years ago by mike.dld

  • Version changed from 2.84 to 2.82

Changed 7 years ago by cfpp2p

data for torrent name torrent

Changed 7 years ago by cfpp2p

comment:5 Changed 7 years ago by cfpp2p

With versions 2.82 or 2.84 and using the attached torrent name.torrent then
rename the file original file name.file_extension
to new file name.file_extension I was able to reproduce the results.

2.82 or 2.84 Rename

The same with compiled trunk correctly renamed the files I suspect because of #5656 fix.

2.84 trunk Rename

comment:6 Changed 7 years ago by DaRieck

I installed the 2.84+ from trunk and it does seem to solve the problem. When will this version be officially realease?

comment:7 Changed 7 years ago by mike.dld

I guess it was already released yesterday as version 2.90.

Note: See TracTickets for help on using tickets.