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.

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to