qvm-open-in-vm works with files. If I run qvm-open-in-vm @dispvm:my-dvm Documents/my-file.ext then it spawns a disp correctly, and if xdg-open file.ext in the dvm can open the file, then the disp opens the file as well.
However, qvm-open-in-vm does not work correctly when I’m giving it a directory. If I run qvm-open-in-vm @dispvm:my-dvm Documents/my-directory/ then it starts a disp correctly, but even though xdg-open path/to/directory/ works in my-dvm, the disp shuts down without doing anything. If you say: it might be that the application to open directories can only open the directory of the dvm but not the one passed to qvm-open-in-vm, then that’s not true in my case.
This is a bug. Either it should not spawn a new disposable and show an error (that it could work only with one file at a time), or it should transfer the entire directory to the new disposable and open it in Thunar, GNOME files, whatever File Manager which is applicable in destination disposable.
I believe there may be expert guys seeing this that may easily go to github and fix the bug and tell the other guys seeing this as well and me what to do to get it fixed, perhaps until The Qubes Team sees it and fix it themselves.
That is after all, if this is a bug in the first place; it might be working with some other people and I’m missing something. Please, anyone seeing this try to qvm-open-in-vm VMNAME path/to/directory and see if it’ll work (make sure that xdg-open path/to/directory works in VMNAME first.)
Is there another way to do the same that qvm-open-in-vm with directories would do?
I don’t want to manually start a disposable then manually copy to it the directory then manually launch a terminal (which I don’t have as I use more-than-minimal VMs those don’t have a terminal emulator, so I have to manually run qvm-console-dispvm to then finally manually run the application with the copied directory as an argument.
I’d say: why not make qvm-open work with directories as well?
The fix that is submitted for the time will show a warning if the target is not a regular file (directory, symlink, block-device, …).
I have been thinking about your request. It is a good feature to have. But most probably for qvm-copy. Not for qvm-open-in-(d)vm. Since the files are literally copied to the destination VM. Not opened (yet).
If the script meets a file with unknown characters, it aborts, with parts of the directory moved/copied with others abandoned. I’ll try and send along the error I recently encountered.
@barto wasn’t those issues, I don’t think, as I’m using 4.2.2. Aside from the expected qubes-fs-tree-check: Refusing to copy unsafe symbolic link warning, there’s also an error about special characters. I, of course, can’t reproduce now.
edit: here it is
qfile-agent: Fatal error: Forbidden character in file or link target. Name might look somewhat like "Downloads/_____________________________,________________________________________________________________________________________.pdf" (error type: Invalid or incomplete multibyte or wide character)
I am requesting qvm-open-in-vm to be able to deal with a directory as it deals with a file. What am I wrong in? Doesn’t it just starts the VM, copy the file to it (how does it do that? Isn’t it by the known qvm-copy already, that already works for directories?) then runs the xdg-open? If yes, then why did The Qubes Team made it only work for a file and URL? Why not make qvm-open-in-vm work with directories?
Anyways, until then, I need another way to do the same that qvm-open-in-vm with a directory would do. Since that’s unrelated to this topic, I’ve created another thread for that.
has bitten me too.