Bug 1122315 - Ktorrent 4.3.1-11.fc20 won't move completed torrents to a CIFS share
Summary: Ktorrent 4.3.1-11.fc20 won't move completed torrents to a CIFS share
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: ktorrent
Version: 20
Hardware: x86_64
OS: Linux
unspecified
low
Target Milestone: ---
Assignee: Roland Wolters
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-22 22:58 UTC by bob
Modified: 2015-06-30 01:05 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-06-30 01:05:57 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
KDE Software Compilation 338010 0 None None None Never

Description bob 2014-07-22 22:58:24 UTC
Description of problem:

Ktorrent offers the option of moving a downloaded set of torrent files to a new location once the download is completed.  Although this function works fine on a local drive, it isn't working with SMB / CIFS.


Version-Release number of selected component (if applicable):

4.3.1-11.fc20 

How reproducible:

every time.

Steps to Reproduce:
1. Configure ktorrent to move completed torrent downloads to a specified folder.
2. Observe successful move when folder is on local device
3. Observe failure to move when folder is on an SMB/ CIFS share.

Actual results:

Failure to move files

Expected results:

Success in moving files

Additional info:

The failure seems to occur under both of these conditions:

1. when the address of the drive is added to the ktorrent configuration using a network address.  example: smb://sharename/path/

2. When the SMB/CIFS share is mounted locally, so that the drive/folder should appear to be local.

This doesn't appear to be a permissions problem -- the same user running ktorrent on the local machine is the same user owning the destination path on the CIFS share.  Additionally, the CIFS share is exported with promiscuous permissions (777) which allows any connected user has read/write/execute privileges.  Dragging and dropping the files using Dolphin works just fine, it's just that Ktorrent isn't providing similar functionality.

Comment 1 Roland Wolters 2014-07-23 21:22:58 UTC
Hej Bob, thanks for your bug report.
Can you please tell us which Samba version is running on the client/server? Also, can you please activate debug logging in Samba for the moment of the move and send us the debug?

Comment 2 bob 2014-08-03 17:26:17 UTC
On the CIFS client, where Ktorrent is running:

<snip>
 # smbstatus

Samba version 4.1.9
PID     Username      Group         Machine                        
-------------------------------------------------------------------

Service      pid     machine       Connected at
-------------------------------------------------------

No locked files
</snip>

On the CIFS server: protocols supported are up to and including SMB3.

<snip>
# smbstatus
max_open_files: increasing sysctl_max (11095) to minimum Windows limit (16384)
rlimit_max: increasing rlimit_max (11095) to minimum Windows limit (16384)

Samba version 4.1.9
PID     Username      Group         Machine                        
-------------------------------------------------------------------

Service      pid     machine       Connected at
-------------------------------------------------------

Registered MSG_REQ_POOL_USAGE
Registered MSG_REQ_DMALLOC_MARK and LOG_CHANGED
No locked files
</snip>

1. Is that information adequate wrt samba versions?
2. which logs do you want to see debug mode?  the server creates lots of logs under different names:

<snip>
# ll /var/log/samba4
total 62028
drwxr-xr-x  2 root  wheel         8 Aug  3 12:14 ./
drwxr-xr-x  4 root  wheel        45 Aug  3 12:00 ../
-rw-r--r--  1 root  wheel  12718050 Aug  3 12:14 log.nmbd
-rw-r--r--  1 root  wheel  47665304 Aug  3 12:21 log.smbd
-rw-r--r--  1 root  wheel    336595 Aug  3 12:13 log.wb-BUILTIN
-rw-r--r--  1 root  wheel   1689424 Aug  3 12:13 log.wb-NAS
-rw-r--r--  1 root  wheel    555514 Aug  3 12:13 log.winbindd
-rw-r--r--  1 root  wheel    212590 Aug  3 12:13 log.winbindd-idmap
</snip>

Comment 3 bob 2014-08-03 18:18:41 UTC
I think we're barking up the wrong tree in assuming that this is a CIFS-related problem.  After a bit more exploring, it seems that Ktorrent is not even attempting to write to the proper directory.  

For example, I configured ktorrent to use ~/Downloads/torrents as the working directory, and to move the downloaded files to ~/Downloads/torrents-completed upon successful completion of the download.  I then populated a queue of torrents to download, and let ktorrent perform the downloads.  Ktorrent successfully moved the files from the local "torrents" folder to the local "torrents-completed" folder, as expected. 

As the next step in the test I then used Ktorrent's configuration menu to create a new destination folder for the completed torrents on an SMB share; I created the new path on the destination CIFS share from within the ktorrent configuration menu, which confirmed ktorrent's ability to read/write to the new SMB share.  This effectively put to rest any concerns that CIFS is causing a problem.

To verify this, I then downloaded some more torrents, and examined some smb logs in debug mode.  Upon completing a download, Ktorrent didn't even attempt to move the files to the proper directory on the SMB share, and the logs showed no activity at all.  Ktorrent instead moved the files to the "torrents-completed" folder on the host machine, a path that doesn't even exist anymore in the ktorrent configuration file.

It would seem that the problem is not with SMB/CIFS.  It would appear that Ktorrent isn't even attempting to write to the proper path.  Instead of using the current/existing path in the ktorrent configuration, ktorrent is using the path that previously existed in the ktorrent configuration, but isn't there any more.  This errant behavior is survived by an exit/restart of ktorrent.  

This behavior would be consistent with permanently associating the "move-to" upon completion path with the torrent at the time that the torrent is placed in the queue, and never re-updating this path information when the config file is changed after the torrent has already been queued.  Essentially, this suggets that you can't reconfigure file paths in ktorrent once downloads have been queued, as the software ignores the path updates.  That would be a design flaw.

Furthermore, if I change the final destination path to an SMB share, and then download a new torrent and place it int he download queue, ktorrent will begin the download into the ~/Downloads/torrents folder, and upon completion, the file should be moved to the SMB share path that was created within the ktorrent config menu.  But instead of moving the file to the proper path, the file just disappears.

This suggetsts that ktorrent is A) associating the final destination path with the torrent at the time that it is queued, and ignores any further updates to the move-to path after the movement to the queue; B) ktorrent's move-to code fails to recognize SMB shares that were created by the ktorrent config menu, and deletes the files when it tries to move them.

I don't think this is a SMB/CIFS problem -- I think it's an internal problem in ktorrent.

Comment 4 Roland Wolters 2014-08-03 19:24:45 UTC
Thanks for the detailed analysis - I filed an upstream bug, let's see what they say.

Comment 5 bob 2014-08-04 09:14:59 UTC
Thanks for your prompt reply, especially since it took me so long to get back with the test results.

I've googled for this problem, and it seems that my conclusions in (A) in the previous post were correct.  Ktorrent's intended design is to associate the move-to path for completed downloads with the torrents at the time the torrents become queued.  One might reasonably expect that changing the paths in the global system configuation would implement a global update to the file paths, but it doesn't.  File paths are associated at the time of queing, and changes to the global file path after queueing do not effect what is already in the queue.  What is already in the queue can have it's destination path updated by right-clicking on the torrent and editing the path.  All things considered, I guess that (A) is a design feature, and not a bug.

Reference:

https://forum.kde.org/viewtopic.php?f=235&t=106446

(B) does look like a bug though.  I created the destination path on the Samba share using ktorrent's configuration menus, so permissions should not be a problem.  When the torrent has completed the download process and it's time to move, ktorrent deletes the file from the working directory without copying it to the SMB share.  Evidently, ktorrent has a bug in it where: 1) it fails to write to the SMB share that it created earlier, and 2) it deletes the file from the source destination without bothering to conform that the write to the destination was successful!  That's definitely a bug.

Thanks again for your help.

Comment 6 bob 2014-08-04 09:17:39 UTC
sorry, there's a typo above.  that last part should read as follows:

2) it deletes the file from the source path without first bothering to confirm that the write to the destination path was successful!  That's definitely a bug.

Comment 7 Roland Wolters 2014-08-04 22:38:05 UTC
Hej bob, thanks for the more detailed analysis. Let's wait what the KDE guys say, maybe they can already point out what the problem is or show a way how to fix that...

Comment 8 bob 2014-10-17 23:15:55 UTC
It's been almost 3 months since the bug was opened.  Any news from upstream?

Comment 9 Rex Dieter 2014-10-18 07:00:25 UTC
https://bugs.kde.org/show_bug.cgi?id=338010

has no activity or news, unfortunately

Comment 10 Fedora End Of Life 2015-05-29 12:26:39 UTC
This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 11 Fedora End Of Life 2015-06-30 01:05:57 UTC
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.