Like many I use an offline disposable qube to view/edit all my files.
I am wondering if there is an elegant way of achieving persistence for selected files. The use case in my mind is the user dictionary for spell checking (e.g. ~/.config/libreoffice/4/user/wordbook/standard.dic).
Obviously I can manually qvm-copy the file in/out of the disposable and even construct keyboard shortcuts for the purpose (my disposable is named). However, maybe there is a better way?
When I want a user setting to persist, there are two basic strategies. Neither of them allows for a change you make in the disposable to persist, however. (I suggest another strategy that does, below.)
Set up the user stuff running the disposable’s template. This is, however, a manual thing and I know you like scripts–you did after all teach me how to use minimal qubes.
Put the necessary file into /etc/skel in the template (i.e., in this case /etc/skel/.config/libreoffice/4/user/wordbook/standard.dic)
If you want it to remember updates–and I suspect you do since it looks like a spell check dictionary) one possible strategy is to create a container file somewhere where dom0 will see it as a block device–(it could even reside on some appvm, though you’ll need to do a losetup on that appvm–that could be done at startup), then mount it to the directory in question when you start your disposable.
Thank you @SteveC.
#!/bin/bash
qvm-run -p offline "cat ~/.config/libreoffice/4/user/wordbook/standard.dic" > ~/bin/data/standard.dic
qvm-run -p offline-dvm "rm -Rf ~/QubesIncoming"
qvm-copy-to-vm offline-dvm ~/bin/data/standard.dic
qvm-run -p offline-dvm "mkdir -p ~/.config/libreoffice/4/user/wordbook"
qvm-run -p offline-dvm "mv -f ~/QubesIncoming/dom0/standard.dic ~/.config/libreoffice/4/user/wordbook/standard.dic"
qvm-run -p offline-dvm "rm -Rf ~/QubesIncoming && sudo poweroff"
notify-send "saved standard.dic"
This works but lacks a certain grace. I am hoping there is a more elegant way that works without me remembering to trigger the keyboard shortcut after adding words to the user dictionary.
My last approach would work, but it would rely on setup each time (assigning the block device, and if it’s in another AppVM, first starting that one and losetup-ing the container), and you would probably want to gracefully unmount and un-losetup the container, too. The good news is, this fails before you access the dictionary, not after you make the change, if you forget to do all of this. So when you forget, you’ll remember.
I actually do something like this (largely to let myself port states of what would otherwise be AppVMs between physical machines on a thumbdrive) but with the added complication that the container on the thumbdrive is encrypted. It’s a simplification of the split-veracrypt I posted about months ago.
I probably don’t understand your goal, but aren’t bind dirs exactly these kind of things for? Even if I misunderstood you, I am happy to be corrected, hopefully to learn some new things.
I first thought of bind-dirs too, but bind-dirs is for making a root directory persistent in an app qube, whereas this is about making a non-root directory persistent in a disposable qube. In other words, it’s like the same problem but “one level down.” I have no idea whether bind-dirs will still work for this.
Not exactly. As @adw pointed out they help bind directories located in the root volume into the private volume. In a disposable there is no persistence by design. So in a way I am trying to achieve an exception against the design. 
The solution @SteveC proposed involves mounting another volume to the disposable and then storing the user dictionary in that volume. But that too, just like my current solution involves manual user action as the qube can’t reach out of itself and mount other volumes. Again: by design, that’s a good thing!
My current solution is a dom0 script manually triggered by a keyboard shortcut that copies the dictionary out of the disposable instance and then into the disposable template (so it’s already there next time a disposable based on that template starts). That’s all done from dom0 because from there you can access / control everything, while you can’t from inside the qube … which is kind of the point of the entire OS. 
… and also the reason why this will stop working as soon as I switch to a sys-gui.
You could automate it with qrexec
My solution can work without manual intervention, if you’re willing to write qvm-exec services and then invoke them from the qube’s bash rc. First invoke the service to get dom0 to attach the storage, then mount it in the qube.
(I do the former but not the latter; I created a desktop shortcut to actually trigger the assign-then-mount sequence. So I deliberately have some manual intervention left in. Actually in my case the intervention is necessary since the container is encrypted and a password must be supplied. But for an unencrypted container there’s no reason this couldn’t be done automagically on qube startup)
Would my solution also stop working from sys-gui?
One thing my solution offers is some security against forgetfulness. If you modify your dictionary you have to remember to do the copy/save immediately afterwards or at least before you shut down the qube. On mine if you forget, you’ll notice the first time you try to use the dictionary and it’s not there; there’s nothing to remember to do afterwards before you shut down.
Message received. It’ll be 2 weeks before I can come back to this but I will update the thread once I tried. Thank you all!
I am just happy to finally be of assistance to someone who has helped me out a lot (largely with stuff about minimal templates you have written, not with direct conversations on the forum).
I’m still most definitely a net debtor!