I’m guessing you opened that. If so, thanks!
Interesting that it was indeed a deliberate decision. It makes no sense to me.
Yes.
In fact a common complaint is a dvm that cannot handle a file, so it hands it off to its default disposable. That can loop forever if it is its own default disposable. I could sometimes be racing to kill dvms faster than they’re being created when this happened.
This seems to encourage that to happen, on top of all of our other complaints about it.
so it hands it off to its default disposable.
How exactly does this work?
I honestly couldn’t tell you now. This was something I was dealing with in my early days of qubes last year (2022), I’d sometimes get into a loop where a disposable kept opening another copy of itself, ad infinitum, because (apparently) its default action for some file type was to open up a disposable…and it was its own default dvm.
I solved that problem by making my actual target disposables have NO default dvm–which to me makes sense; that VM is a destination, not a way point. Then I was just left with having to make sure the target disposable knew what to do with the file type, otherwise it would fail in other, more graceful ways.
(So you may be wondering why I am griping about this if my target DVMs have default dvm set to none–it’s because not every DVM I have is a final destination. In fact almost all of my VMs are disposables that connect to offline storage. In most cases they are named disposables, but web browsing uses a disp1234 type disposable.)
Again, this becomes more likely if a disp1234’s template is set up so that disp1234’s default dvm is that same template (regardless of what that template’s default template is)…which again appears to have been done deliberately for some reason I cannot fathom.