Hello Valery,
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.
Cheers Norman