New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using "Move To Other AppVM" fails poorly if non-existant #1090

Closed
bnvk opened this Issue Jul 29, 2015 · 3 comments

Comments

Projects
None yet
3 participants
@bnvk

bnvk commented Jul 29, 2015

If I select a file using the Nautilus File Manager and select "Move To Other AppVM" and then input a non-existent AppVM name, the dialogue disappears the same as when I input an existing AppVM and then nothing else happens. This is the same behaviour with "Copy To Other AppVM" as well.

This experience I think could be easily mis-understood as "the task completed" if a user doesn't know better / view the file's disappearing or verifies in the desired AppVM.

At the very least Qubes should notify the user The [name of] AppVM you entered does not exist and perhaps even better, provide a dropdown menu of the AppVMs available for file transfering

@nrgaway

This comment has been minimized.

Show comment
Hide comment
@nrgaway

nrgaway Jul 29, 2015

I get a dialog that opens that states something like this when the other AppVM does not exist: "Domain 'AppVM' doesn't exist (Service qubes.Filecopy called by domain vmname). Is this issue with a Debian AppVM? Sometimes I have seen the dialog existing but not in focus.

In regards to the drop-down, I believe that may cause a security implication since that would expose the other VM names to the AppVM.

nrgaway commented Jul 29, 2015

I get a dialog that opens that states something like this when the other AppVM does not exist: "Domain 'AppVM' doesn't exist (Service qubes.Filecopy called by domain vmname). Is this issue with a Debian AppVM? Sometimes I have seen the dialog existing but not in focus.

In regards to the drop-down, I believe that may cause a security implication since that would expose the other VM names to the AppVM.

@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Jul 29, 2015

Member

Regarding dropdown:
There is already functionality which provides recently used VM names there.
We don't want to expose full VMs list, but there is another option: #910

Regarding original bug - is there anything special about that source VM? Was it set to be autostarted? What desktop environment chosen during installation? The default (KDE + Xfce)?

Member

marmarek commented Jul 29, 2015

Regarding dropdown:
There is already functionality which provides recently used VM names there.
We don't want to expose full VMs list, but there is another option: #910

Regarding original bug - is there anything special about that source VM? Was it set to be autostarted? What desktop environment chosen during installation? The default (KDE + Xfce)?

@marmarek marmarek added this to the Release 3.0 milestone Aug 4, 2015

@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Sep 1, 2015

Member

@bnvk Are you able to reproduce the problem, or it happened just once? Every time I tried, I get error message that target VM doesn't exists.
Anyway if it happen to you again, check /var/log/qubes/qrexec.VMNAME.log in domo (replace VMNAME with name of VM from where you've tried to copy the file).

Member

marmarek commented Sep 1, 2015

@bnvk Are you able to reproduce the problem, or it happened just once? Every time I tried, I get error message that target VM doesn't exists.
Anyway if it happen to you again, check /var/log/qubes/qrexec.VMNAME.log in domo (replace VMNAME with name of VM from where you've tried to copy the file).

@marmarek marmarek added the worksforme label Sep 1, 2015

@marmarek marmarek closed this Sep 1, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment