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.
> The move modifier is Ctrl on it's own. Should of course read shift, oops.
Moving bug to target of drag operation
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.
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.
(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 )
... which means the modifiers are only evaluated, when the mouse button is released, not when the drag is started. Intended?
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.
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?
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!
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!