When using bluedevil to receive a file from a remote device, set to confirm receiving files (i.e. with the "Accept automatically" option set to "Never" or "Trusted devices"), accepting the transfer from the popup notification seems to accept and then cancel the transfer immediately. The notification says: <Device name> is sending you the file <filename> with buttons "Accept" and "Cancel". Clicking "Accept" removed the notification but the sending device immediately says "Transfer forbidden by target device". The following messages appear in the debug log: kded5(2810)/bluedevil ObexAgent::authorizePush: ObexAgent-AuthorizePush kded5(2810)/bluedevil ReceiveFileJob::init: ReceiveFileJob: kded5(2810)/bluedevil ReceiveFileJob::init: Name: "20170221_082842.jpg" kded5(2810)/bluedevil ReceiveFileJob::init: Filename: "" kded5(2810)/bluedevil ReceiveFileJob::init: Status: 0 kded5(2810)/bluedevil ReceiveFileJob::init: Type: "image/jpeg" kded5(2810)/bluedevil ReceiveFileJob::init: Size: 1315964 kded5(2810)/bluedevil ReceiveFileJob::init: Transferred: 0 kded5(2810)/bluedevil ReceiveFileJob::init: ObexSession: kded5(2810)/bluedevil ReceiveFileJob::init: Source: "00:15:83:6D:4B:55" kded5(2810)/bluedevil ReceiveFileJob::init: Destination: "60:AF:6D:70:20:F0" plasmashell(3875)/default NotificationsEngine::Notify: New Notification: "Galaxy S5 (60:AF:6D:70:20:F0)" "Galaxy S5 is sending you the file 20170221_082842.jpg" 0 & Part of: 0 kded5(2810)/bluedevil ReceiveFileJob::slotAccept: ReceiveFileJob-Accept kded5(2810)/bluedevil ReceiveFileJob::slotAccept: TempPath "/home/jjm/.cache/obexd/20170221_082842.jpg1" kded5(2810)/bluedevil ReceiveFileJob::slotCancel: Cancel Push kded5(2810)/bluedevil ObexFtp::sessionRemoved: Removed Obex session is not ours "/org/bluez/obex/server/session3" The file quoted as TempPath above exists but is zero size. No file is saved to the configured download directory.
There is a suspicious use of the KNotification signals in ReceiveFileJob::showNotification(). The signals are connected: KNotification::action1Activated -> ReceiveFileJob::slotAccept KNotification::action2Activated -> ReceiveFileJob::slotCancel KNotification::closed -> ReceiveFileJob::slotCancel The last of these makes sense, to decline the file transfer if the notification is closed or times out. However, the API documentation for KNotification::closed says: Emitted when the notification is closed. Can be closed either by the user clicking the close button, the timeout running out or when an action was triggered. I haven't looked at the KNotification code for this, but from the description it would appear that closed() signal is sent, in addition to action1Activated(), when the "Accept" button is clicked. This would account for the calls to slotAccept and then slotCancel in the log.
Thanks, that's exactly what was wrong. I wonder how it worked before. Theoretically, the cancel should be rejected by obexd because the transfer was already accepted, but apparently that's not what is doing. This should fix it: https://phabricator.kde.org/D4744
Git commit def41978a6330097ddb191328185fa79a1d63df4 by David Rosca. Committed on 24/02/2017 at 10:44. Pushed by drosca into branch 'Plasma/5.8'. ReceiveFileJob: Don't cancel the request right after accepting it KNotification::closed is emitted also when one of the notification actions was triggered. FIXED-IN: 5.8.7 Differential Revision: https://phabricator.kde.org/D4744 M +3 -1 src/kded/receivefilejob.cpp M +1 -0 src/kded/receivefilejob.h https://commits.kde.org/bluedevil/def41978a6330097ddb191328185fa79a1d63df4