My personal wishlist
norman.feske at genode-labs.com
Tue Apr 2 10:34:16 CEST 2019
thanks for the background info about extended attributes.
> mandatory to be existed when opening the file). So, EA's on FAT32 are
> laying around near the file itself, in the same directory, in a hidden
> file. The disadvantage is that EA files are laying around everywhere,
> like a trash. So, if a file system doesn't support EA's, they can be
> emulated like this.
I admittedly have not much clue about file systems. To me as a user,
features like this (this also goes for the strange "resource forks" of
old Mac OS) look like glorified directories. They seem to be just more
complicated, less transparent, and cause friction when moving data
across file systems. Given my poor background, please take the following
with a grain of salt.
I wonder, in situations where meta data has to contain a lot of domain
knowledge, wouldn't sqlite be a good way to organize it?
In situations where meta data are simple annotations to files (like
storing the icon for a file), why can't both the file and the meta data
go to into a directory? This is the way Risc OS (and also today's Mac
OS, AFAIK) deal with the situation.
Hence, there is currently no plan to extend Genode's file-system session
with extended attributes.
Valery's remark about an emulation scheme looks good to bridge the gap.
This way, such a feature can be implemented within the libc where the
libc would rely on some conventions. E.g., when asked for the extended
attributes for a certain 'file', the libc may - under the hood - read
the meta data from a file called '.xa/file'. Yes, this would spill the
'.xa' directories here and there but it leaves the complexity out of
base mechanisms like the VFS or the file-system session.
Dr.-Ing. Norman Feske
https://www.genode-labs.com · https://genode.org
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
More information about the users