[vbox-dev] Drag-n-drop alive again

[Michael Thayer]

Hello Sergiy,

What do you (or anyone else who is interested) think of the following
idea?  We could use a permanent shared folder rather than one or several
temporary ones.  This folder could be created automatically when the VM
is created (or started) and could map, on the host, to some directory
under the $VBOX_HOME/<VM Name> configuration directory - perhaps
$VBOX_HOME/<VM Name>/Drop.  It could be mapped automatically when the
Guest Additions start up.  When files are dragged from the host to the
guest, a symbolic link to the files could be created in that drop
directory, which would solve the copy time issues (would this also work
on Windows hosts?)

I also wonder whether, rather than trying to hide all this from the
user, we could make the drop directory part of the documented interface,
so that the user can see what dropped files are currently available to
the guest and clean them up themselves as needed?  Alternatively, the
Guest Additions or the host could clean up when the VM is shut down.

Regards,

Michael

Sergiy Byelozyorov wrote:
> Hello everybody,
> 
> After long break, I continue my attempt to enable drag-n-drop feature
> in VirtualBox. So I decided to start with the Linux guest. I created
> another daemon to listen for incoming drag events from host (similar
> to clipboard and autoresize feature), but I still need to implement
> it's functions. First of all we need to figure out how will it work.
> 
> Let's summarize the algorithm. After being started guest application
> will inform host to enable drag-n-drop actions. Then when item (file
> or folder) is dragged over VirtualBox window, the host will inform
> guest about drag process, create (read-only/full access) temporary
> shared folder (for the folder containing that item) and will provide
> guest with item name and any other necessary information about drag
> action. Guest application will mount newly created folder to the
> temporary local folder and initiate drag action as it's own. We cannot
> close temporary share after drop since local application may want to
> use item later too (for example if we opened file in editor that way,
> the application will try to save changes later). We need to keep list
> of them and close only when daemon is shut down.
> 
> We can also open only one temporary shared folder when starting daemon
> and use it to transfer files, however in this case we will need to
> copy every dropped file to this folder and this will take some time
> (guest will have to be frozen during this time). Making changes to
> dropped files also becomes a problem. In this case, however, we do not
> allow local application to access any files that are lying in the same
> folder as the one which was dropped.
> 
> If we are going to use drag-n-drop only as convenient way to copy
> files, then we can use read-only shared folder for every dropped file
> and close it right after the file will be copied locally.
> 
> Any comments, ideas?