On 03/10/2017 12:22 PM, Jean-Philippe Ouellet wrote: > On Fri, Mar 10, 2017 at 12:57 PM, Marek Marczykowski-Górecki > <[email protected]> wrote: >> On Thu, Mar 09, 2017 at 06:43:04PM -0800, anoa wrote: >>> In terms of concept, I have already started thinking about how to >>> implement this, however I would like to clarify one thing first before >>> presenting a design as the issue description doesn't really make this >>> too clear. >>> >>> Are we implementing MIME-handling to open a specific file/type in >>> DisposableVMs only, or should the user be able to choose/enter any one >>> of their installed VMs? As a Qubes user I would like the ability to open >>> all PDFs in, say, my work AppVM, rather than only being able to only set >>> global rules for files to open in Disposable VMs. >> >> Technically it's indeed very similar, but in practice it doesn't make >> much sense - if you want to open some file always in the same >> non-disposable VM, simply keep the file there. >> >> IMO much more important (and not so easy) part is to keep information >> which files should be opened where. For example flag files downloaded >> from the internet to open in Disposable VMs (even when moved out of >> "Downloads" directory), but files converted using qvm-convert-pdf open >> locally. > > There are standardized extended filesystem attributes [1] which are > widely adopted now, and should be a good starting point for > implementing this. > > [1]: https://www.freedesktop.org/wiki/CommonExtendedAttributes/ > > > Example: > $ getfattr -d genode-foundations-16-05.pdf > # file: genode-foundations-16-05.pdf > user.xdg.origin.url="https://genode.org/documentation/genode-foundations-16-05.pdf" >
Hey Jean-Philippe, This is very useful, thank you. The `attr` package is not installed in Whonix, Ubuntu or Debian by default, so we will have to include this in our templates for this to function seamlessly. Furthermore, while Nautilus preserves x-attributes on copy/move/cut, Dolphin only supports it on move/cut, not copy. Some discussion may be necessary on whether it /should/ be preserved on copy, as you are essentially making a new file, even if the contents are initially the same. I believe that whichever is decided on, however, it should be consistent across all supported file managers, which may require a patch on one of them. It seems that what causes the above is that adding the -a flag to cp allows cp to respect x-attr's and will copy them accordingly. It seems that Konsole does not do this, while Nautilus does. Windows also apparently supports Extended File Attributes on FAT, HPFS and NTFS[0], so this should also work as a solution on Windows-based systems as well! [0] https://en.wikipedia.org/wiki/Extended_file_attributes#Windows_NT Thanks, Andrew Morgan -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/oa0d9p%24jru%241%40blaine.gmane.org. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: OpenPGP digital signature
