Drag-and-Drop of text/uri-list to Dolphin or Konqueror - am I expecting the right thing?

Development
1

I am working on a Qt/KDE application for scientific data acquisition that manages captured experimental data in files in a private directory, expecting full control over their lifetime and content. In the GUI, the files are represented by rows of a TableModel, and I’d like to include drag-and-drop to a filemanager, or mail program, or whatever, so that file copies can be exported easily. However, when dragging to Dolphin or Konqueror as text/uri-list with CopyAction as default action, I still get the option to move, copy or link the data. When selecting “move”, the files happily get moved from the private directory, even if the files are set to readonly.

Am I expecting the right thing? How can I prevent the files being “stolen” from under my app’s nose?

What I’ve tried: I’ve created a hidden directory .dnd and placed hard links to the actual file in there, planning to delete the .dnd directory after the operation (triggered by the “destroyed” signal of the QMimeData object holding the urilist). Unfortunately, this deletion happens as soon as the mouse button is released and before the menu (“Move”, "Copy, “Link”) is shown - thus the temporary source files are already gone when the user makes a choice. The “Link”-option would be undesired anyway…

I am not sure whether the issue is in the receiving or the sending application. Any hint to the right direction is appreciated.

Thanks!

UH

2

hi, welcome.

this is more of a data management question than anything specific to do with KDE software, but from what you describe, i would suggest changing the permissions on the files so that they are not owned by your user, and therefore can only be copied, not moved.

is this data captured by your user acct?

could it be set up so that the data is captured by a different user acct? and then selectively shared with yours?

3

Hi, thanks for your feedback!

So far the data are indeed captured by the same user account, and I’d rather keep it that way - anything else might complicate the software setup (dependence on presence of alternative user accounts).

Since posting the above text I have played around with the permissions of the file and the enclosing directory, and indeed this can be used to get rid of the “move” option. The “link” option however appears to be always present - as is manifest in the kde sources: /kf6-qt6/frameworks/kio/src/widgets/dropjob.cpp#0338. I haven’t found out whether the “default action” hint of the DND operation is evaluated at all in the kio framework. Having an “external” link to the “internal” files would of course mean that they can be manipulated from outside, which is just as undesirable as their removal.

Probably I’ll just have to live with the possibility that the internal files might disappear or be modified, set a watch on the directory and remove them from the GUI when they are gone.

Thanks again,

UH

4

If the “internal” file is read-only, it can’t be written to via the symlink in the external directory.

5

Good point. Makes sense anyway to switch files to read-only after data capture is completed. That would only leave the issue of possible stale links if the internal file is removed.

Nonetheless, it would be good to investigate how KDE’s file widgets such as the views in Dolphin uses the XDND protocol’s XdndAction… information - or whether Qt sends the right thing here…