...
My gut is that if extended attributes are "universal enough" (and usable enough), and we can easily implement DOS attributes over them, modulo slight differences in the API, then there isn't really any need to implement something truly portable. I could be wrong about this, though.
What platforms do you consider to be important here? I ask because the current implementation (without fallback) supports Linux, Mac OS, FreeBSD, and NetBSD. That seems to me to be the "important" ones.
There is also the storage of [NT extended-attribute (EA)](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntifs/nf-ntif...) values to consider, when we move toward a non-stub implementation of this feature.
Perhaps it would be preferable to produce a design that can be encompass all these issues.
The NTFS spec separates DOS Attributes (Flags) from Extended Attributes (EA). I would not recommend mixing the two, for fear of an accidental name collision. If you want to design a fallback mechanism that supports both of these features the same way, then I would suggest structuring it like so: ``` .WINE_METADATA/<filename>/<feature> ``` That way when a copy/move operation is performed on a file then it's easier to copy both features together.
I don't have a good read on this, personally. I suppose it at least partly depends on whether NT extended attributes are used by any program. I'm at least not aware of any usage?
I am not aware of any non-MS usage, but it is documented. So, I would not be surprised if some copy protection mechanism does something with it our chooses to do so at some point in the future. I do know that the Single Instance Storage (SIS) minifilter driver uses an extended attribute to "back reference" the single instance files to find the duplicates/originals.
I think working out the design completely before submitting any patches would probably be a good idea.
...
If the OS list above is sufficient then I think we're covered, if we need a fallback implementation then this probably needs a little more thought.