Hi,
I have recently noticed some behavior. I was going to copy a file to a disposable vm and then do something with the file.
right click => copy to vm opens the qubes dialog. Then I choose “Disposable VM (default dvm)”
This works but after the copy operation, the disposable vm shuts down.
This led me to think that if I had mistakenly chosen “Move to VM” => “Disposable VM”, my file would have been moved to a disposable vm, and after the move operation the disposable vm would shut down, deleting the file permanently.
If you start the dispvm in that way, it executes exactly one call (the copy process). When the call is finished, the disp vm is closed.
If you use “open in dispVM” for the file, it will opened in the associated application inside the disp vm and you can do, what you have to do with that file.
The other way is starting a disp vm and then copy the file into that already started vm. Then the vm is running until you shut it down and you can do, what you have to do.
Here is a list of user-oriented alternatives that can be done. It is a corner case, as I had not encountered for years until yesterday, and I don’t know if an elegant solution can be implemented.
As a user, I would like to be warned before my file is deleted (unless I don’t want to get warned), even if it is deleted as a result of a seemingly valid operation.
As a user, I would not like to instantiate a Disposable VM through a ‘copy/move to VM’ operation if the VM will be shut down after the operation. Namely, as a user, I would like the Disposable VM that was instantiated by a ‘move/copy to VM’ operation remain running after the move/copy operation. Therefore, either the “Disposable VMs” should not be in the target VM list (but running dispVMs can exist of course), or, the instantiated dispVM should remain running.
The move/copy to VM are not special to disp vms.You can move/copy files to every vm, no matter if its a template, app-vm or a disp vm.
In case of disp vm, one thing must be absolutely clear. ALL what you move/copy to or creates in that VM disappears, when the vm is going down. Thats the purpose of that type of vms.
So a extra warning “Attention, the DISP VM will do her job” is imho meaningless.
In a qubes system, you are root, with other words in the unix/linux world, you are like god.
In unix/linux, the system principle is, if you are like god, you know, what you do, opposite to other OS (like Windows).
And secondly, a user has the absolute power over his own files, so he is like god in his own little world.
If you are like god, you will not asked “Are you sure”, like it is on windows often.
You can love it or hate it.
On the other side, linux/unix sysadmins hate it, if a programm asks “Are you sure”, because that blocks or complicates automatic running scripts.
So every question in an unix/linux system has to be absolute required, no matter, if you are familar with the system or not.
Linux/unix estimates, an user is an expert on all tasks, that he is allowed to do, windows estimates, that an user don’t know, what he is about to do.
I think it would be better to remove the disposable templates from the
list of available targets - that way you can still copy/move to existing disposables, but not pointlessly copy/move to an
instantiating disposable.
I’ll raise an issue over at GitHub.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
I agree and like the Linux desktop experience. I have been happily using Linux for 25+ years
Many users are not tech-savvy, implying that they might need clear directions on the UI, or the UI should minimize the possibility for them the make errors. I am talking about the python gui components specific to Qubes, not the command line stuff.
Also, there are similar behavior in other functionality that makes one think that this can be handled. E.g., when you mount a USB drive to a disposable VM, a disposable VM is created and the drive remains mounted in a newly created dispVM. Previously I was creating an offline disp vm manually, and mounting the USB storage and do the work. Recently the UI has added this feature to automate this, which was very helpful. When I saw the disposable templates in the qvm-copy/move target list, I thought there was an analogy to that behavior, which might be confusing.
I agree that it would be consistent with the ability to attach a device to a new disposable qube. I clearly don’t feel like a god and copying a file to a new disposable should be meaningful.
