Bug 313407

Summary:	Drag and drop with Alt key modifier (link) moves files without warning.
Product:	[Unmaintained] kio	Reporter:	pbhj
Component:	general	Assignee:	David Faure <faure>
Status:	RESOLVED WORKSFORME
Severity:	critical	CC:	adawit, cfeck, frank78ac
Priority:	NOR	Keywords:	triaged
Version:	4.9.3
Target Milestone:	---
Platform:	Ubuntu
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description pbhj 2013-01-17 14:15:49 UTC

The default modifier in KDE to create a soft-link when drag-dropping is Alt. However when dragging and dropping from Digikams search results (or albums) to a file-manager (Dolphin 2.1 under KDE 4.9.3 on Kubuntu 12.10) Digikam instead performs a "move" operation, deleting files from the original locations without notice to the user.

Without the Alt modifier the WM gives an option to move, copy or link. In this situation, for some reason (maybe new key-bindings?) Ctrl+Shift is used as the link modifier. The move modifier is Ctrl on it's own.

Expecting files to have been linked I deleted the supposed links, on returning to Digikam I saw that the drag-drop+Alt have instead caused a move to be performed. 

Whilst in this instance I recovered the files from recycle there is no undo for the move operation and so the files could not be returned to their proper place in the file tree without substantial effort.

Reproducible: Always

Steps to Reproduce:
1. Select file in album or search results in Digikam.
2. Drag-drop to file manager whilst holding Alt key.

Actual Results:  
Files are moved instead of linked, no warning is given or option to select copy/move/link.

Expected Results:  
Soft links are created at the drop location; alternatively is modifier is incorrect a menu dialog gives the possible options (as it does when no modifier is used).

Listed as critical as this causes data loss.

Comment 1 pbhj 2013-01-17 14:19:47 UTC

> The move modifier is Ctrl on it's own.

Should of course read shift, oops.

Comment 2 Marcel Wiesweg 2013-01-17 17:52:25 UTC

Moving bug to target of drag operation

Comment 3 Frank Reininghaus 2013-01-17 19:46:54 UTC

Thanks for the report, but I cannot reproduce the problem.

Note that Dolphin does not perform the detection of modifiers and moving/linking/copying itself, it relies on lib/konq and KIO for that -> reassigning.

Comment 4 Christoph Feck 2013-01-17 20:42:19 UTC

Where is the data loss? As far as I understand the bug, data is moved, not deleted. And I think the "source" application (digiKam in this case) has to pass the selected modifiers to kio somehow.

Comment 5 Frank Reininghaus 2013-01-17 20:52:18 UTC

(In reply to comment #4)
> And I think the "source" application (digiKam in this case) has to
> pass the selected modifiers to kio somehow.

lib/konq reads the modifiers in the "destination" application in

KonqOperations *KonqOperations::doDrop( const KFileItem & destItem, const KUrl & dest, QDropEvent * ev, QWidget * parent, const QList<QAction*> & userActions  )

Comment 6 Christoph Feck 2013-01-17 21:05:50 UTC

... which means the modifiers are only evaluated, when the mouse button is released, not when the drag is started. Intended?

Comment 7 Frank Reininghaus 2013-01-18 13:23:42 UTC

I think it is intended, yes. The idea is that you can press the modifier key *after* the drag has been started. Note that even the indicator next to the mouse curser changes if you do that, and that happens outside our control inside Qt, I think. So it seems to me that the way it is supposed to work is that the modifier state at the time of the drop is important.

Comment 8 Dawit Alemayehu 2013-07-06 04:42:04 UTC

This works just fine when you drag and drop files while pressing the Alt key in Dolphin or Konqueror. If I split a window and drag and drop selected files from one folder into another while pressing the Alt key (Note you can only press the Alt key after starting the drag even), symlinks are created in the destination folder. No move operation is performed. 

Hence something else must be happening in Digikam or this issue has already been resolved. Do you still see this issue in KDE 4.10 or higher?

Comment 9 Andrew Crouthamel 2018-09-24 02:15:24 UTC

Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!

Comment 10 Andrew Crouthamel 2018-10-27 02:36:20 UTC

Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!